# dsh-Fang 开源许可与商业化方案（AGPL 核心 + MIT 生态 + 商业 Relay）

> 落地文件：`LICENSE-CORE`（AGPL-3.0 全文）· `LICENSE-SDK`（MIT）· `LICENSE-COMMERCIAL`（草案）·
> `CLA.md` · `NOTICE`（逐目录许可地图）· 本文件（决策与边界分析）。
>
> ⚠️ **本文件是工程/产品层面的方案说明，不是法律意见。** 正式对外发布前请律师审阅
> CLA、商业合同与本文 §4 的边界结论。

---

## 1. 决策摘要

| 层 | 内容 | 协议 | 目的 |
|---|---|---|---|
| 核心层 | Orchestrator / Forker / RestartGuard / Adapter / Scorer / Router / Healer / Approver / HotReloader / BufferKeeper / Auditor / SessionCatalog / 容器执行器 | **AGPL-3.0-or-later** | 云厂商把它包装成托管服务必须开源其修改 |
| 生态层 | 插件 SDK、CLI（`tools/fangctl.mjs`）、模板、示例 | **MIT** | 个人/小团队零摩擦使用与再开发 |
| 商业层 | Relay 服务器（联合开发/云备份/Token API/团队协作/审计导出/SLA）、企业功能（SSO/组权限） | **商业闭源** | 收入来源；从第一天就是付费功能 |

### 为什么不是 BUSL / SSPL

- **BUSL**：有"延时开源"限制、OSI 不承认其为开源；对"激发社区活力"的目标是硬伤——个人开发者会因为
  "这不是真开源"而绕道。
- **SSPL**：要求把整个服务栈（负载均衡、管理界面等）开源，企业法务普遍列为高风险，不利于生态扩散。
- **AGPL**：被 OSI 承认；"网络传染性"精确对准"只提供服务、不分发副本"的规避路径；
  国内已有基于 AGPL 的"微擎商城"案（法院认定违反传染性条款，判停止运营并赔偿 37.8 万元），
  说明 AGPL 在中国的司法环境下有可执行性。**AGPL 是威慑，不是技术强制**——真正的护城河在 §5。

---

## 2. 商业模型

### 2.1 Open Core（主推）

- 免费：AGPL 核心 + MIT 生态 + 单用户审计。
- 付费：Relay 服务器全部功能 + 企业功能 + SLA。
- **纪律：永远不要把已经免费的功移到付费墙后面。** Relay 从设计之初就是独立服务，不存在"收回免费功能"。

### 2.2 双许可证（对云厂商的直接变现通道）

核心层保持 AGPL-3.0，同时提供商业授权：云厂商不愿遵守 AGPL 开源义务时，按"白名单域名/部署范围 +
版本覆盖"购买闭源商用许可（参考 MySQL / Qt 模式）。**CLA 是这个路径的法律前提**（见 §3）。

### 2.3 收入结构的现实预期

开源代码本身不直接收费，收入来自围绕它的服务、托管与企业功能：有开发者靠开源五年盈利约 200 万人民币；
有产品全开源（Apache）但通过托管服务月入 14.5 万美元。**不要指望协议本身带来收入**——
协议只解决"别人能不能白嫖"，收入来自 Relay 的运营、SLA 信誉与用户关系。

---

## 3. 本仓库的落地清单（已完成）

```
dsh-fang\
├── LICENSE-CORE          AGPL-3.0 全文（34,523 bytes，gnu.org 原文）
├── LICENSE-SDK           MIT 全文
├── LICENSE-COMMERCIAL    商业许可草案（含评估/生产/OEM 三档与占位价格）
├── CLA.md                贡献者许可协议（含"再许可/双许可"授权，双许可路径的前提）
├── NOTICE                逐目录/逐文件许可地图 + 第三方组件归属
├── LICENSES/
│   └── cordis-MIT.txt    vendored schemastery/cosmokit 的上游 MIT 许可与归属
├── docs/LICENSING.md     本文件
├── sdk/                  MIT 生态层：插件模板 + 示例 + 说明
├── relay-server/         商业层占位（闭源，不随开源包发布）
├── enterprise/           商业层占位（闭源，不随开源包发布）
└── （所有源码文件头部带 SPDX 标识；package.json license = AGPL-3.0-or-later）
```

- 每个 `.mjs/.js/.cs/.ps1` 文件头都有 `SPDX-License-Identifier`；`cordis.patch*.yml` 有许可头注释。
- `test/licensing.test.mjs` 会检查：许可文件存在且正确、分层标注无遗漏、package.json 许可字段、
  NOTICE 覆盖三层目录、vendored 文件保留 MIT。**许可分层从此有回归测试，防止漂移。**

---

## 4. AGPL 与 MIT 的 DSH 生态：兼容边界（最重要的一节）

### 4.1 问题

DSH 宿主是 MIT。当前 v2.1.0 的瓮城核心是**以 Cordis 插件形式加载进 DSH 进程**的（`fang-orchestrator`
等行在母体 profile 里挂载）。这在法律上有两种主张：

- **较有把握的主张**：插件是独立作品，通过 Cordis 的运行时接口与宿主结合；AGPL 义务只覆盖插件自身，
  DSH 仍是 MIT。这也是大多数"MIT 宿主 + 第三方插件"的现实做法。
- **风险主张**：瓮城核心与宿主深度共享服务（loader、webServer、agent、session projections），
  若被认定为"与宿主结合成一个更大作品"，AGPL 的传染性可能被主张延伸到宿主整体——
  对用户与 DSH 生态都是寒蝉效应。

**结论：不赌解释。** 对开源分发（个人/小团队本地使用）风险可接受；对"云厂商托管"场景，
必须把边界做成**进程边界**，而不是依赖法庭上的解释。

### 4.2 推荐架构：AGPL 核心独立进程 + MIT 轻量 bridge

```
┌──────────────────────────────┐        HTTP / loopback / token
│ DSH（MIT 宿主）               │◀─────────────────────────────┐
│  只装一个 MIT 的 bridge 插件   │                              │
│  （~200 行 HTTP 客户端 + 面板）│                              │
└──────────────────────────────┘                              │
                                                              ▼
                                          ┌────────────────────────────────┐
                                          │ fangd（AGPL-3.0 独立进程/服务） │
                                          │  Orchestrator / Forker /        │
                                          │  RestartGuard / Adapter / …     │
                                          └────────────────────────────────┘
```

- **bridge 插件（MIT）**：只做两件事——把 UI/工具请求转发给 `fangd` 的 `/fang/api/*`；
  把结果呈现回 DSH。它不包含任何编排逻辑，可自由随 MIT 生态使用。
- **fangd（AGPL）**：独立 Node 进程，持有全部核心逻辑；云厂商若把它当服务提供，必须开源其修改。
- 进程边界让"AGPL 传染 MIT 宿主"的主张失去事实基础——两者只通过 HTTP 消息交互，
  各自是独立程序（GPL 社群长期接受的"独立进程/管道通信不构成结合作品"共识）。

### 4.3 落地状态与迁移路径

- **当前（v2.1.0）**：仍是 in-process Cordis 插件形态（母体单机使用、开发体验最好）。
- **迁移（建议 v3）**：把插件对 `ctx` 的依赖收敛为一个 `KernelHost` 接口（effect/provide/get/inject/
  webServer/logging）→ `fangd` 用最小 host 实现启动同一批插件 → DSH 侧改成 MIT bridge 插件 →
  协议沿用现有 `/fang/api/*` 与 Adapter 协议（零协议改造）。
- **双模式**：个人本地可继续用 in-process（便利）；对外分发/托管部署用 daemon 模式（合规）。
  两种模式共享同一核心代码，只有宿主适配层不同。

### 4.4 已知的"服务隔离式规避"

云厂商可以让 AGPL 核心作为独立后端、前端自研，主张"只是调用"。这不是 AGPL 的漏洞，而是它的边界：
**协议是威慑，不是技术强制**。兜底在商业层壁垒——Relay 的团队协作、Token 路由、云备份、SLA 信誉、
用户关系不是"拿核心代码包装一下"能复制的。

---

## 5. 发布前合规 checklist（必须逐项完成）

1. **替换占位**：`NOTICE` / `LICENSE-COMMERCIAL` / `CLA.md` 里的维护者主体、邮箱、价格、SLA 数字。
2. **律师审阅**：CLA 的再许可条款、商业许可合同、域外主体/税务结构。
3. **商标**："dsh-Fang / 瓮城" 名称与 logo 的商标注册策略；AGPL 不授予商标许可（在 README/NOTICE 写明）。
4. **第三方审计**：vendored 代码（cordis MIT）归属核对；运行 `test/licensing.test.mjs`；
   下个版本接入 SPDX/scancode 类工具做全仓扫描。
5. **CLA 自动化**：接入 CLA bot 或在 PR 模板强制签署声明；维护 `AUTHORS`/贡献者名单。
6. **出口/合规**：若含加密（Relay 端到端备份），按目标市场评估出口管制与数据合规（GDPR/PIPL）。
7. **安全披露渠道**：`SECURITY.md` + 漏洞响应流程（商业客户的 SLA 依赖它）。
8. **"不撤回"承诺**：已发布版本保持其发布时的许可；永不移除已开源的代码/功能。

---

## 6. 风险清单

| 风险 | 说明 | 缓解 |
|---|---|---|
| AGPL 执法成本 | 跨国取证、诉讼成本高 | 优先发律师函 + 公开违约证据；商业客户合同约定审计权 |
| 服务隔离式规避 | 云厂商只调用核心服务 | 商业层壁垒（§4.4） |
| 双许可路径被 CLA 拖累 | 历史贡献缺 CLA 无法再许可 | 项目早期就强制 CLA；历史贡献补签或重写 |
| 社区反感"开源不彻底" | 核心层可读但传染 | 生态层 MIT + 明确边界文档 + 不撤功能 |
| 商标被抢注 | 云厂商用同名分发 | 尽早注册商标与域名 |
| vendored 代码许可混入 | 第三方 MIT 被误标 AGPL | NOTICE 单列 + 回归测试 |

---

## 7. FAQ

**Q：个人能在公司里用吗？** AGPL 允许内部使用；但如果你把修改后的核心**对外提供网络服务**，
必须向用户提供对应源码（AGPL §13）。内部自用不触发分发义务。

**Q：插件作者要开源自己的插件吗？** 不。通过公开 API/进程边界与核心交互的独立插件可以自选协议
（MIT/闭源皆可）——这正是生态层 MIT 的意义。

**Q：买了商业许可，AGPL 义务就没了？** 商业许可只覆盖商业层；若同时购买核心层闭源授权，才豁免
对应的 AGPL 义务（双许可证路径）。

**Q：为什么不用 DCO 而用 CLA？** DCO 只证明"有权提交"，不授予再许可/双许可权利；双许可证模式必须 CLA。