整理开源组件与模型许可证义务

能帮做什么

项目依赖清单写着开源，不代表所有组件、权重和数据都有相同使用条件。WorkBuddy 可以读取准确版本的许可文本与研发提供的使用方式，逐项整理待履行义务及需法务解释的问题。

准备什么

提供研发确认的组件或模型清单、版本与取得地址、对应许可证及附加条款、拟修改分发部署方式、已有声明和授权。只有许可标签时先补完整文本；代码来源、链接方式与发布对象由技术人员确认，不让模型猜测。

具体怎么做

第一步：把对象和版本对应清楚

分别列源代码、模型权重、数据和附属素材，保留上游来源及准确许可版本。不能用仓库首页标签覆盖所有文件，也不把基座许可直接当成衍生数据许可。

第二步：提取条件与触发行为

从原文整理使用、修改、分发、网络提供、署名和通知等条件，标注明确文字和待解释项。具体义务是否触发要对照实际使用，不使用“碰到某许可就全部开源”的泛化判断。

第三步：核对已有履行材料

将声明文件、源码提供安排、第三方告知和批准例外对应到确认义务，检查缺失与版本冲突。扫描结果只是线索，不能自动判断许可兼容或侵权。

第四步：形成发布前专业问题

列对象、用途、证据、缺口和技术法务需确认事项。若不能确定适用关系，保留条件，不靠改许可证名称、删署名或大量改写代码来假装消除义务。

可直接交给 WorkBuddy 的完整要求

请依据准确版本的清单、许可证全文、附加条款及研发确认的使用方式，整理各组件或模型的条件和履行材料。区分代码、权重、数据，逐项引用许可原句、触发行为及待解释点，核对声明、通知和其他确认义务。不要凭标签认定自由商用，不把所有GPL、AGPL、MIT或模型许可统一处理，不判断改写即可免责。输出对应表和专业问题，不修改许可、不删除署名、不发布项目、不承诺权利完整。

得到什么

得到逐组件义务表和发布前待办。例如所用权重另有附加使用限制，就应单列全文与用途问题；依赖包有不同子许可，则标出需要技术确认的文件范围。

怎么检查

研发核对实际版本和集成方式，法务核对原句及条件解释。确认清单没有遗漏第三方素材，未核实来源不应被标成已授权，已有商业授权与开源条件分别记录。

异常处理

无法取得许可、分叉版本关系不清或依赖扫描与清单冲突时先补证。许可之间是否兼容由专业人员分析，不由工具自行选择最宽松版本。

人工决定

技术确认依赖与发布事实，法务决定义务、兼容性和许可风险，负责人批准发布方案。此任务整理文本条件，不是许可证合规认证。