开源视频模型的许可证被反复检查——“licence-verified”、“商用要确认许可”、“Apache 2.0”——但当用户把Wan、Hunyuan、LTX、Open-Sora的权重混在同一个工作流里、产出的视频又用于商业分发时，许可证的边界到底该按“每个模型单独看”还是按“整条工作流的输出”来追溯？

一、问题定义：为什么“每个模型单独看”不够

先把场景钉死。假设一个团队构建了如下推理图：用Wan-T2V或Wan-I2V生成基础片段，用HunyuanVideo做镜头延展或风格补全，用LTX-Video做低延迟草稿以筛选prompt，用Open-Sora做对照实验或补充素材，最后经超分与插帧模型放大到4K/60fps，输出成片用于品牌广告投放。整条链路里，每个权重文件都自带LICENSE，每个仓库README都写着“licence-verified”或“商用需确认”。问题在于：当这些权重不产生衍生权重、只产生视频像素时，许可证义务究竟附着在哪个对象上？

“每个模型单独看”这一路径的合理性在于：许可证是授权人与被授权人之间的法律关系，授权对象是特定作品（权重、代码、文档），而非抽象的“工作流”。只要每个权重在其自身许可范围内被使用，似乎就完成了合规。但这一路径的漏洞同样明显：它假设“使用”是一个离散动作，而实际工程中，“使用”是连续的分发行为——模型权重被下载、容器镜像被构建、推理服务被部署、成片被交付给客户。许可证的多数实质性义务（署名、相同方式共享、禁止商用、输出限制）恰恰在“分发”节点被触发，而分发对象是整条流水线的产物。

本文评述：许可证合规不是“文件级”问题，而是“行为级”问题。把每个模型的LICENSE读一遍，只能回答“我有没有权利下载和运行”，回答不了“我有没有权利把运行结果卖出去”。后者需要沿数据流反向追溯，这正是输出端追溯的必要性来源。

更麻烦的是“混合”带来的语义漂移。单一模型时，许可证条款与输出之间是直接映射；多模型串联时，输出同时是A模型的“衍生输出”、B模型的“输入”、C模型的“后处理结果”。若A许可证要求“输出不得用于军事用途”，B许可证要求“商用需单独授权”，C许可证是Apache 2.0（对输出不作限制），那么最终成片的合规状态不是三者简单取交集，而取决于哪个许可证的条款在哪个节点被触发、以及触发后的义务能否被下游继承。

笔者认为，这里存在一个被普遍忽视的区分：权重许可证约束的是“权重的复制与分发”，输出许可证约束的是“输出的使用与再分发”。多数开源视频模型许可证对输出采取“不主张权利”或“有限主张”的态度，但少数许可证（尤其是带“商用需确认”“可接受使用政策”的）会把约束延伸到输出。因此，“每个模型单独看”只能覆盖第一层，“整条工作流输出追溯”才能覆盖第二层。二者是必要与充分的关系，不是替代关系。

二、许可证传播链：四类对象与三个触发节点

要回答“按哪个追溯”，先要把工作流拆成可追溯的对象。笔者提出“许可证传播链”（License Propagation Chain, LPC）框架，把一条视频生成流水线中的合规对象分为四类：代码（推理脚本、调度器、WebUI）、权重（.safetensors/.ckpt/.gguf）、数据（训练集、微调集、评测集）、输出（视频帧序列、封装文件、元数据）。四类对象的许可证可以不同，且传播规则不同。

与之对应，有三个触发节点：获取节点（下载、克隆、拉取镜像）、运行节点（推理、微调、蒸馏）、分发节点（交付成片、公开部署、嵌入产品）。多数许可证在获取节点只要求保留声明，在运行节点几乎不设限（除非涉及再分发权重），真正的义务集中在分发节点。这一观察与开源许可证法学的通行结论一致：版权许可的义务由“发行/分发”行为触发，而非由“使用”行为触发。

本文评述：命题2是工程上最容易被误判的地方。团队常以为“大部分模型是Apache 2.0，所以整体没问题”，但合规是合取逻辑——一个禁止商用的节点足以否决整条链路。反过来，一个宽松节点不能“治愈”一个严格节点。这一点与软件供应链许可证兼容性分析同构：GPL组件不能因为旁边有MIT组件就变成可闭源分发。

还需要区分“衍生权重”与“衍生输出”。若团队用LoRA对Wan做微调，产出的LoRA是衍生权重，受基座许可证约束；若只是用Wan生成视频、再用视频训练另一个模型，则涉及“输出是否可被用于训练”的条款，这在不同许可证中差异极大。LTX-Video与Open-Sora的许可证对“输出用于训练”的态度并不一致，工程上必须逐条核对，不能凭“都是开源的”一概而论。

三、主流视频模型许可证横向对照

下表按公开仓库与模型卡信息整理，聚焦“商用”“输出限制”“再分发”“衍生权重”四个维度。需要说明：许可证会随版本更新，表中为撰写时点的公开信息，工程落地必须以锁定版本的LICENSE原文为准。表中“需确认”表示条款存在解释空间或需联系授权方，不代表禁止。

表中信息刻意保守。原因在于：视频模型的“许可证”往往由三层构成——代码LICENSE、权重LICENSE、模型卡中的可接受使用政策（AUP）。三者可能不一致，且AUP常以“补充条款”形式出现，法律效力取决于其是否被有效纳入许可。工程上若只看仓库根目录的LICENSE文件，极易漏掉模型卡里的使用限制。笔者建议把“模型卡AUP”作为独立合规对象纳入清单，而不是当作说明文档。

本文评述：Apache 2.0 常被当作“万能通行证”，但它只解决版权与专利许可，不解决训练数据来源、肖像权、深度伪造披露等下游问题。一条用Apache 2.0权重生成的视频，仍可能因训练数据含受版权保护素材而面临输出端主张。许可证合规与内容合规是两条并行线，不能互相替代。这一点在商业分发场景中尤其关键：客户合同里的知识产权保证条款，往往比开源许可证更严格。

进一步看，“licence-verified”这类标签本身不构成法律保证。它是社区或平台的自检标记，表示“有人核对过许可证文件存在”，不表示“核对过条款与你的使用场景匹配”。把标签当作合规结论，是把“文件存在性”误当“义务满足性”。笔者认为，工程团队应建立自己的“条款—场景”映射表，而不是依赖第三方标签。

四、三色合规矩阵与工程落地步骤

把分析转成可操作工具。笔者设计“三色合规矩阵”：行是工作流节点（文本编码、基础生成、超分、插帧、封装），列是合规维度（商用许可、署名义务、输出限制、再分发、数据来源）。每个单元格标三色：绿 表示明确允许且义务可满足；黄 表示需确认或存在解释空间；红 表示明确禁止或义务不可满足。整条链路的商用可行性 = 所有单元格无红色，且黄色单元格均有书面结论。

落地步骤建议如下，按顺序执行，每步产出可归档的证据：

1. 版本锁定：记录每个权重的仓库commit、文件哈希、LICENSE与模型卡快照。许可证会变，快照是唯一可复现的证据。
2. 对象拆分：把代码、权重、数据、输出分别登记，避免“一个仓库一个许可证”的粗粒度登记。
3. 条款抽取：从LICENSE与AUP中抽取五类条款（商用、署名、输出、再分发、数据），填入矩阵。
4. 合取判定：按LPC命题2做AND运算，任一红色即判定该工作流不可商用，或替换该节点。
5. 黄色收敛：对黄色单元格，通过阅读FAQ、提交issue、联系授权方获取书面答复，转为绿或红。
6. 输出端复核：对最终成片单独评估内容合规（肖像、商标、深度伪造披露），与许可证合规分开归档。
7. 持续监控：订阅仓库release与LICENSE变更，版本升级触发矩阵重算。

本文评述：这套流程的价值不在“复杂”，而在“可审计”。合规的本质不是一次性判断，而是可被第三方复现的证据链。很多团队失败不是因为用错了许可证，而是因为无法证明自己当时核对的是哪个版本、依据哪条条款。版本锁定与快照归档，是成本最低、收益最高的工程动作。

拓展阅读方面，开源许可证兼容性分析可参考SPDX规范与OSI的许可证列表；视频模型的具体条款建议直接查阅各仓库的LICENSE与模型卡，例如Wan 官方仓库、HunyuanVideo 仓库、LTX-Video 仓库、Open-Sora 仓库。许可证文本的权威解释可参考Apache 2.0 官方文本与SPDX 许可证列表。

五、案例推演：一条混合工作流的完整追溯

构造一个可复现的推演案例（以下为模拟场景，用于演示方法，不代表任何真实企业的实际配置）。工作流：LTX-Video生成草稿筛选prompt → Wan-I2V生成主片段 → HunyuanVideo做镜头延展 → 超分模型放大 → 插帧至60fps → 封装交付。输出用于商业广告。

按LPC框架逐节点填矩阵：LTX节点在“商用”列为黄色（需确认具体版本条款），Wan节点为绿色（Apache 2.0，需保留声明），Hunyuan节点为黄色（自有条款，需确认使用场景），超分与插帧若为Apache 2.0则为绿色。合取判定：存在黄色，不能直接判定可商用，需先收敛黄色。收敛方式：对LTX与Hunyuan分别获取书面确认或替换为明确允许商用的权重。若无法收敛，则整条链路不可商用——注意，不是因为Wan有问题，而是因为合取逻辑。

这个推演揭示一个反直觉结论：工作流的商用可行性由最严格的节点决定，而不是由最宽松的节点决定。团队常把注意力放在“主模型”上，忽视草稿模型或后处理模型的许可证，结果在交付前才发现某个辅助权重禁止商用。笔者认为，工程上应把“许可证审查”前移到选型阶段，把三色矩阵作为模型选型的硬性评分项，而不是上线前的检查项。

另一个常见误区是把“输出端追溯”理解为“对成片做版权检测”。二者不同：输出端追溯是沿DAG反查每个节点的许可证义务是否被满足；版权检测是判断成片是否与既有作品实质性相似。前者是合规工程，后者是侵权风险控制，二者需要同时做，但不能互相替代。

本文评述：案例推演的方法论价值在于把“法律问题”转成“图论问题”。一旦工作流被表示为DAG，许可证合规就变成带标签的图遍历：每个节点带许可证标签，边表示数据流，输出端合规状态是路径上标签的合取。这使得合规检查可以被脚本化、被CI集成，而不是依赖人工记忆。笔者建议把许可证标签写入模型注册表（model registry），与权重哈希绑定，推理服务启动时校验标签完整性。

六、局限、争议与前沿预判

必须承认本框架的局限。第一，许可证条款的解释存在司法辖区差异，“商用”的边界在不同法域下并不一致，本文不提供法律意见。第二，部分模型的可接受使用政策以网页形式动态更新，快照只能固定时点状态，无法预判未来变更。第三，训练数据来源的合规性无法仅从许可证文本推断，需要数据卡（data card）与溯源信息，而当前多数视频模型的数据卡并不完整。第四，合取逻辑在“模型仅用于内部评测、不对外分发”的场景下可能过严，此时应改用“分发触发”判定而非“使用触发”判定。

争议点集中在“输出是否应被视为衍生作品”。一种观点认为，生成模型的输出与训练数据不存在固定表达映射，不应视为衍生；另一种观点认为，若输出可被证明与训练样本高度相似，则可能构成侵权。本文评述：这一争议短期内不会有统一结论，工程上的稳健策略是“不依赖争议结论”——即无论输出是否衍生，都确保许可证义务被满足、内容合规被检查。把合规建立在“大概率不侵权”的推测上，不是工程思维。

前沿预判方面，笔者认为三个方向值得关注。其一，模型许可证的“机器可读化”：若许可证以结构化字段（允许商用、署名要求、输出限制）随权重分发，LPC框架可直接自动化，减少人工解释成本。其二，输出水印与来源标注（content provenance）技术的成熟，可能把“输出端追溯”从法律问题部分转为技术问题——可验证的来源链能降低举证成本。其三，模型注册表与CI/CD的集成，会把许可证检查变成构建流水线的标准环节，类似软件供应链中的SBOM（软件物料清单）。

对从业者的建议是：不要等待标准统一。在标准到来之前，用版本锁定、三色矩阵、DAG标签三件套建立自己的可审计流程，成本可控且能直接用于客户沟通。客户合同里的知识产权条款往往比开源许可证更严格，提前把许可证证据链准备好，能显著降低商务谈判摩擦。拓展学习可参考OSI 许可证中心与美国版权局关于AI与版权的公开材料，以及C2PA 内容来源标准。

七、结论与操作清单

回到最初的问题：许可证边界该按“每个模型单独看”还是按“整条工作流的输出”追溯？本文的结论是：逐模型合规是必要条件，输出端追溯是充分条件。只做前者，会漏掉输出限制与合取逻辑；只做后者，会失去条款依据。正确做法是把工作流表示为带许可证标签的DAG，按LPC框架做合取判定，用三色矩阵收敛不确定性，用版本锁定保证可审计。

操作清单浓缩为五条：锁定版本并快照LICENSE与模型卡；拆分代码/权重/数据/输出四类对象；填三色矩阵并做AND判定；黄色项必须书面收敛；输出端内容合规与许可证合规分开归档。做到这五条，混合工作流的商用分发就有了可复现的合规证据链，而不是依赖“licence-verified”这类标签的心理安慰。