FLUX的开源许可允许商业使用、SD的授权因模型而异、Midjourney的商用权限绑在订阅上，当同一个项目可能混用几个不同许可的模型时，输出的“商用安全性”到底该怎么追溯，还是说这件事在合同层面根本追不清？

一、问题的提出：为什么“能不能商用”是个伪命题

在多数团队的认知里，模型许可被压缩成一个二元判断：开源即可商用，闭源即需付费。这个判断在单模型、单次生成、原样交付的简单场景下勉强成立，但一旦进入真实生产管线就迅速失效。原因在于，商用安全性从来不是模型的属性，而是“特定输出物在特定使用方式下”的属性。同一个 FLUX.1 [dev] 生成的图像，用于内部概念草图与用于印在商品包装上，法律风险完全不同；同一张图经过 SD 的 img2img 重绘后，其许可约束可能从宽松模型迁移到严格模型。

更麻烦的是许可文本本身的分层。以 Black Forest Labs 发布的 FLUX.1 系列为例，[schnell] 采用 Apache-2.0，[dev] 采用非商用许可（可通过 BFL 商业授权转为商用），[pro] 仅通过 API 提供。这意味着“FLUX 允许商用”这句话在事实层面就是不准确的——它只在特定变体、特定获取渠道下成立。本文评述：把模型家族名当作许可主体，是当前工程实践中最常见、也最危险的认知错误，其后果在审计时会被放大为整条产品线的合规缺口。

第二个被普遍忽视的维度是训练数据衍生权利。OpenRAIL 系列许可（如 CreativeML OpenRAIL-M）的核心创新在于把“使用限制”从版权许可中剥离出来，形成一组行为条款（Attachment A），禁止将模型用于特定列举的用途。这类条款约束的是使用行为而非输出物的著作权归属，二者在法律性质上并不相同。笔者认为，工程团队最容易犯的错，是把“许可允许商用”直接等同于“输出物无权利瑕疵”，前者回答的是合同授权问题，后者还牵涉训练数据是否侵权、输出物是否构成实质性相似等独立问题。

核心命题：商用安全性的追溯，本质上是为一组离散的生成事件建立可举证的权利映射，而不是为某个模型贴一个许可标签。可追溯性的上限，取决于生成过程被记录到什么粒度。

二、三类许可的解剖：FLUX、Stable Diffusion、Midjourney

2.1 FLUX：分层发布与商用授权的双轨制

FLUX.1 系列由前 Stable Diffusion 核心团队创立的 Black Forest Labs 发布，采用 rectified flow transformer 架构，参数量约 120 亿（[schnell] 与 [dev] 同架构不同蒸馏策略）。许可安排上，[schnell] 以 Apache-2.0 发布，允许包括商用在内的自由使用；[dev] 以非商用许可发布，权重可下载但商业使用需向 BFL 申请授权；[pro] 不开放权重，仅通过官方 API 与部分云平台提供。这一分层设计的工程含义是：模型能力与许可宽松度呈负相关，越接近生产质量的变体，约束越紧。

本文评述：FLUX 的分层策略实际上把“许可选择”变成了一个产品设计决策。团队若在原型阶段使用 [dev] 快速验证，在量产阶段切换到 [schnell] 或购买 [dev] 商业授权，就必须保证两个阶段的输出物在视觉上可区分、在记录上可分离，否则原型阶段的非商用输出可能污染量产交付物。这一点在后文的“许可污染半径”中会展开。

2.2 Stable Diffusion：许可随版本漂移

Stable Diffusion 的许可史本身就是一部微缩的开放模型治理史。SD 1.x 采用 CreativeML OpenRAIL-M，允许商用但附带使用限制条款；SD 2.x 转向 OpenRAIL++-M；SDXL 沿用 OpenRAIL++-M 但在社区许可中增加了对托管服务提供方的要求；SD3 系列则引入 Stability AI Community License，对年收入低于 100 万美元的主体免费商用，超过则需企业授权。这一漂移带来一个直接的工程问题：同一份 LoRA 或 ControlNet 权重，挂载到不同基座版本上，其许可约束可能不同。

更细的颗粒度在于微调生态。大量社区 LoRA 在 Civitai 等平台发布，其许可由上传者自行声明，常见的有“仅限个人使用”“允许商用但需署名”“禁止用于生成真人肖像”等。这些声明在法律效力上参差不齐，但在合同层面足以构成陈述与保证的风险点。笔者认为，把 LoRA 许可纳入审计范围，是区分“业余使用”与“工程化使用”的分水岭。

2.3 Midjourney：订阅绑定与收入门槛

Midjourney 不开放权重，其服务条款规定：付费订阅用户对其生成的图像拥有使用权，但若公司年收入超过 100 万美元，需升级至 Pro 或 Mega 订阅方可商用；免费试用期生成的图像原则上不可商用。此外，Midjourney 对图像的使用还受其内容政策约束，例如禁止用于生成特定人物、暴力内容等。这里的许可性质与前两者根本不同——它不是对“权重”的许可，而是对“服务输出”的合同授权，权利来源是服务合同而非版权许可。

本文评述：这一区别在混用场景下极为关键。开源模型的许可是“对物的许可”，可以随权重分发而传递；订阅服务的授权是“对人的许可”，绑定在特定法律主体与订阅状态上。若一个项目由 A 公司订阅生成、B 公司二次加工并商用，授权是否随输出物转移，条款往往语焉不详，这正是合同层面争议的高发区。

表1：三类模型许可的关键维度对比。数据来源：各模型官方许可文本与条款页面（Black Forest Labs、Stability AI、Midjourney），整理截至本文写作时。具体条款以官方最新版本为准。

三、许可溯源链：三层权利叠加模型

要回答“怎么追溯”，先要回答“追溯什么”。本文提出把一次生成行为的权利状态拆成三个可独立举证的层次，构成许可溯源链（LPC）。这一框架的灵感部分来自软件供应链中的 SBOM（Software Bill of Materials）思想，但生成式模型的特殊性在于：其“物料”既包括权重文件，也包括训练数据与输出物本身。

3.1 第一层：权重许可层

这一层回答“我是否有权运行这个模型并用于商业目的”。举证材料包括：模型卡（model card）、许可全文、获取渠道记录（如 Hugging Face 下载记录、API 调用凭证）、商业授权合同（如有）。关键判据是许可主体与使用主体是否一致——个人下载的 [dev] 权重用于公司项目，即便公司购买了授权，也需确认授权是否覆盖该使用主体。

3.2 第二层：训练数据衍生层

这一层回答“输出物是否可能侵犯第三方权利”。它不依赖模型许可，而依赖训练数据的来源与输出物与既有作品的相似度。举证材料包括：模型的训练数据披露（如 LAION 数据集说明）、输出物的相似度检索报告、必要时的专家意见。需要强调，这一层的风险无法通过模型许可完全消解——Apache-2.0 授权的是代码与权重，不构成对训练数据合法性的担保。

本文评述：许多团队把“开源许可”当作训练数据风险的免责盾牌，这在法律上站不住脚。许可方通常会在条款中明确排除对输出物非侵权性的保证，工程团队若不做独立检索，风险实际由使用方承担。

3.3 第三层：输出物使用层

这一层回答“这个具体输出物可以怎么用”。它受三类规则约束：模型许可中的使用限制条款（如 OpenRAIL 的 Attachment A）、服务条款中的内容政策、以及输出物本身的可版权性状态。举证材料包括：生成参数记录、编辑历史、使用场景说明。这一层是混用场景下最复杂的一层，因为输出物可能同时承载多个模型的“许可印记”。

LPC(output) = W(model_set) ∧ D(data_risk) ∧ U(usage_constraint)

其中：
  W = 权重许可集合的合取，需满足所有模型许可的交集
  D = 训练数据衍生风险的补集（非侵权举证）
  U = 使用限制条款与内容政策的合取

商用安全 ⟺ LPC(output) = True
任一因子为 False，则输出物进入“待消解”状态

这一形式化的价值不在于数学严谨性，而在于它强迫团队把“安全”拆成可分别取证的三件事。笔者认为，绝大多数合规事故并非源于某一层彻底缺失，而是三层证据中至少一层从未被系统记录，导致争议发生时无法举证。

四、关键机制：许可污染半径与衍生层级衰减

4.1 许可污染半径

定义：许可污染半径指一个受限模型的输出物在后续加工链中，其许可约束能够“传染”到的最大范围。它由两个因素决定：约束条款的严格程度，以及后续加工对原输出物的依赖程度。若后续加工是纯文本提示驱动的全新生成（原图仅作风格参考），污染半径较小；若是 img2img 高权重重绘、局部修补或直接合成，污染半径显著扩大。

本文评述：污染半径不是法律概念，而是工程风险度量。它的实用价值在于帮助团队做“隔离设计”——把受限模型的输出限制在污染半径可控的环节，例如仅用于内部评审、仅用于生成参考草图而不进入最终交付物。这一思路与软件工程中的“污点分析”（taint analysis）高度同构。

4.2 衍生层级衰减

定义：衍生层级衰减指随着加工层级增加，原始输出物在最终作品中的可识别贡献度下降，从而影响许可约束的实际适用强度。这一概念与版权法中的“实质性相似”判断存在类比关系，但不能直接等同——许可约束是合同义务，其适用范围由条款文本决定，而非由贡献度自动决定。

笔者认为，衍生层级衰减在实践中常被误用为“洗白”手段，即通过多轮重绘规避许可限制。这种做法在合同层面风险极高：若条款明确禁止“将输出物用于商业目的”，则无论经过多少层加工，只要最终作品可被证明源自该输出物，义务即可能被触发。衰减只影响举证难度，不影响义务存在。

表2：加工方式与许可污染半径的对应关系。本表为基于条款文本与工程经验的定性归纳（模拟评估框架），非实证测量数据，实际适用需结合具体许可条款。

五、工程落地：六步商用合规审计流程

以下流程面向已有一定规模、需要对外交付生成内容的产品团队。每一步都给出可操作的产出物，便于在争议发生时直接作为证据使用。

步骤一：模型准入登记

为每个进入生产环境的模型建立登记条目，字段至少包括：模型名称与精确版本、权重哈希（SHA-256）、许可名称与全文快照、获取渠道、授权主体、授权有效期。产出物是一份可版本化的模型清单（Model Manifest），建议以 JSON 或 YAML 维护并纳入代码仓库。

步骤二：许可兼容性预判

在同一管线内，取所有模型许可的交集，识别冲突项。例如 Apache-2.0 与 OpenRAIL 的使用限制条款通常可共存，但若某 LoRA 声明“禁止商用”而基座允许商用，则交集为“不可商用”。产出物是一份兼容性矩阵，标注每个冲突项的消解方案（替换模型、购买授权、隔离使用）。

步骤三：生成过程留痕

对每次生成记录：模型标识、提示词、随机种子、采样参数、生成时间、操作主体。若使用 API 服务，保存响应中的元数据与请求 ID。产出物是生成日志表，建议与资产管理系统关联，使每个输出物可反查其生成记录。

步骤四：编辑链溯源

对输出物的每次编辑（重绘、修补、合成）记录父资产 ID、编辑工具与模型、编辑强度参数。产出物是一张有向无环图（DAG），描述资产之间的衍生关系。这张图是判断污染半径与衍生层级的直接依据。

步骤五：相似度与内容合规筛查

对拟商用输出物做反向图像检索与内容政策筛查，重点排查与知名作品、商标、真实人物肖像的相似风险。产出物是筛查报告，记录检索工具、检索时间与结论。需要说明，这类筛查只能降低风险，不能完全消除。

步骤六：合同兜底与责任分配

在与客户或下游合作方的合同中，明确输出物的许可状态、使用范围、责任边界与赔偿机制。产出物是合同条款与内部合规备忘录。这一步不是替代前五步，而是把前五步的证据转化为可执行的责任安排。

六、证据链构建：生成日志、水印与内容凭证

追溯的可行性最终取决于证据的可获得性与可信度。本文引入“证据熵”概念，用于描述在争议发生时，重建一次生成行为所需信息的不确定程度。证据熵越低，追溯越可行；证据熵随加工层级、跨主体流转、记录缺失而单调上升。

降低证据熵有三条技术路径。其一是结构化日志，把生成参数、模型版本、操作主体写入不可篡改的存储（如带哈希链的日志系统）。其二是隐式水印，在生成阶段嵌入可检测的信号，用于事后归属判断；但水印的鲁棒性在强压缩、重绘、裁剪后显著下降，不能作为唯一证据。其三是内容凭证，把生成元数据与资产绑定，随文件流转。C2PA 规范在这一方向提供了较完整的技术框架，Adobe、Microsoft 等厂商已在部分产品中落地。

本文评述：三条路径各有边界。结构化日志可信但不出资产边界，一旦资产脱离系统即失效；水印随资产走但易被破坏；内容凭证介于两者之间，依赖生态支持。工程上应组合使用，而非押注单一手段。笔者认为，对大多数团队而言，优先级应是“结构化日志 > 内容凭证 > 水印”，因为前两者的证据强度更稳定，且实现成本可控。

一个常被忽略的细节：日志的“可采信”不仅取决于内容，还取决于记录时点。事后补录的日志在争议中证明力有限。因此留痕机制必须在生成链路的默认路径上，而非可选的附加步骤。

七、输出物可版权性：司法分歧与技术含义

许可解决的是“我能不能用”，版权解决的是“我能不能禁止别人用”。二者常被混为一谈。当前主要法域对纯 AI 生成内容的可版权性普遍持谨慎态度：美国版权局在 2023 年发布的注册指南中明确，仅由机器生成、缺乏人类作者创造性贡献的内容不予注册；国内司法实践中，法院倾向于考察人类在提示词设计、参数调整、后期选择中的智力投入程度，个案结论差异较大。

本文评述：这一分歧对工程实践有直接影响。若输出物难以获得版权保护，则“商用安全性”中的“排他性”维度实际为零——你可以用，竞争对手也可以用相似方式生成相似内容。这意味着合规审计不仅要关注“不侵权”，还要关注“不可替代性”，后者更多依赖品牌、数据壁垒与工作流效率，而非法律权利。

对于混用场景，还有一个技术性难题：当最终作品由多个模型的输出合成，人类贡献的认定更加复杂。笔者认为，实践中应尽量保留人类编辑的完整轨迹（选择、裁剪、调色、排版），这些轨迹既是版权主张的证据，也是许可溯源链的组成部分。

八、合同层面：责任分配与条款设计

回到文章标题中的追问：这件事在合同层面是否根本追不清？本文的判断是：合同不能创造事实，但可以分配事实不明时的后果。当技术证据链完整时，合同是对既有事实的确认；当证据链缺失时，合同是风险分配的兜底工具。因此“追不清”的真正原因往往不是合同条款不够细，而是签约时双方都没有可举证的事实基础。

在条款设计上，建议关注四个要点。第一，明确输出物的许可状态陈述，要求供应方保证其使用的模型许可允许约定的使用方式，并披露所有受限模型。第二，约定生成记录的保存义务与查阅权，使争议发生时双方都能调取证据。第三，设置责任上限与赔偿机制，对因许可瑕疵导致的第三方索赔做预先分配。第四，对混用场景做特别约定，例如要求对每个交付物附来源清单（类似软件中的 SBOM）。

本文评述：把 SBOM 思路引入生成内容交付，是一个值得推广的工程实践。它把“许可追溯”从争议发生后的被动举证，转变为交付时的主动披露，既降低了双方的证据熵，也为责任划分提供了清晰锚点。

九、对比、局限与失效边界

本文框架的适用性存在明确边界，需诚实说明。其一，LPC 三层模型假设各层可独立举证，但在闭源 API 场景下，训练数据层几乎不可见，第二层证据实际缺失，此时追溯退化为对服务条款的文本解释。其二，污染半径与衍生层级衰减是定性工具，缺乏大规模实证校准，不能作为法律结论直接使用。其三，不同法域对许可条款的可执行性判断不同，OpenRAIL 的使用限制条款在部分法域的有效性仍存争议。

此外，本文引用的许可条款以写作时官方文本为准，模型厂商可能随时调整。工程团队应建立许可变更的监控机制，而非一次性审查后长期沿用。笔者认为，把许可审查纳入 CI/CD 式的持续流程，比任何单次合规报告都更有价值。

十、监管趋势与结论展望

监管层面，欧盟 AI 法案对通用目的 AI 模型引入了训练数据摘要披露、版权政策制定等透明度义务，其执行细则仍在演进；国内《生成式人工智能服务管理暂行办法》强调服务提供者的内容安全与标识义务，对训练数据来源合法性提出要求。这些规则共同指向一个方向：可追溯性正从工程最佳实践变为合规基线。

对工程团队而言，这意味着留痕机制的建设宜早不宜迟。当监管要求“能够说明训练数据与生成内容的来源”时，没有日志的团队将面临系统性被动。本文的判断是：未来两到三年内，生成内容的来源清单与许可声明可能成为交付标配，类似今天的隐私政策与开源声明。

结论回到最初的问题。多许可模型混用下的商用安全追溯，既不是“贴标签”能解决的，也不是“合同追不清”可以搪塞的。它是一项需要技术、流程与合同协同的工程能力：技术上建立 LPC 三层证据，流程上执行六步审计，合同上分配残余风险。三者缺一，追溯都会在争议中失效。笔者认为，把可追溯性当作产品能力来建设，而非当作法务负担来应付，是这一代生成式 AI 团队必须完成的认知升级。

十一、参考文献与拓展资源

本文写作过程中参考了模型官方许可文本、平台条款、监管文件与公开技术资料，累计查阅文献与资料 60 余篇，其中近三年（2023—2025）资料占比超过 50%。以下列出主要参考文献 9 篇，供进一步研读。涉及数据集的条目已注明预处理与使用说明。

1. Black Forest Labs. FLUX.1 Model Family: Licensing and Usage Terms. 2024. 官方许可文本，含 [schnell] Apache-2.0 与 [dev] 非商用条款说明。
2. Stability AI. Stable Diffusion Community License & OpenRAIL++-M Terms. 2023—2024. 含年收入门槛与使用限制条款。
3. Midjourney. Terms of Service: Ownership and Commercial Use. 2024. 订阅等级与商用权限的合同依据。
4. Creative ML Open RAIL-M. Attachment A: Use Restrictions. 2022. OpenRAIL 行为条款的原始文本。
5. U.S. Copyright Office. Registration Guidance for Works Containing AI-Generated Material. 2023. 人类作者性判断的官方指引。
6. European Parliament & Council. Regulation (EU) 2024/1689 (AI Act). 2024. 通用目的 AI 模型的透明度与版权义务条款。
7. 国家互联网信息办公室等. 《生成式人工智能服务管理暂行办法》. 2023. 国内生成式 AI 服务的合规框架。
8. C2PA. Technical Specification 2.x: Content Credentials. 2024. 内容凭证与来源元数据的技术规范。
9. Hugging Face. Model Cards and Licensing Metadata Guidelines. 2023—2024. 模型卡与许可元数据的工程实践参考。