许可证与代码来源卫生
一句话定义
许可证卫生 = 引入的每一份第三方代码（依赖与 AI 逐字产出的片段）都过一遍「家族识别 → 兼容性 → 归属」检查，并默认要求 AI 产出原创实现而非复现已知开源代码。
为什么重要
依赖的许可证问题传统而致命：把 GPL 家族代码链进闭源产品可能触发开源义务纠纷。AI 引入了新维度：模型可能逐字复现训练数据中的知名开源片段（连同其许可证义务），而你无法从一段「流畅的代码」看出它的来源。多数司法辖区对「模型输出是否构成对训练材料的复制」尚无定论——这正是要把「来源卫生」做成流程规则的原因：在法律明确之前，用工程惯例控制风险。
前置知识
kp-021（审查清单——来源检查是合并前的固定动作）。
核心概念
- 许可证两大家族：
- 宽松型（permissive）：MIT、BSD、Apache-2.0——义务轻（保留版权声明，Apache 另有专利授权与变更声明要求），商业闭源友好。
- 著佐权型（copyleft）：GPL 系（LGPL 较弱、AGPL 最强）——分发/网络服务场景下要求开放衍生源码，闭源产品链入即高风险。
- 兼容性方向：检查的是「我的项目许可证能否容纳它」，链入更严格的许可证会把整个产品拖入其义务范围。
- AI 产出特有风险：逐字复现训练数据中的标志性代码段（识别信号：非必要的独特注释、非常规命名、与知名项目高度相似的结构）。
- 归属记录：引入来源、许可证、决策人与日期，入档可查。
原理与机制
卫生流程的机制是「把法律判断降维成工程检查」：工程师不需要成为律师，只需要执行家族识别与登记，把真正的疑难（跨许可证边界、AGPL 网络条款、AI 输出版权争议）上报给有决策权的人。对 AI 产出的处理逻辑同理：无法保证模型不复现，所以用「提示端要求原创 + 审查端识别复现信号 + 相似度抽查」三层降低概率，并用「禁止让 AI 抄指定开源项目的实现方式」这类规则文件红线减少高风险行为。这一切的前提是登记——无记录的引入在纠纷时无法自证。
实例或案例
操作步骤（引入第三方代码三步）：
- 家族识别：查包的 LICENSE 文件（不是 README 的一句话），确认家族与版本。
- 兼容性：对照团队许可证政策表（见下）；不在表内 → 上报决策，不自行判断。
- 归属：在第三方声明文件（NOTICE/credits）登记名称、版本、许可证、引入人。
团队政策表（起步模板）：
允许直接链入：MIT / BSD / Apache-2.0 / ISC
需审批后使用：LGPL / MPL / EPL
默认禁止链入闭源产品：GPL-2.0 / GPL-3.0 / AGPL（SaaS 场景 AGPL 一票否决）
不可授权给 AI：含未公开源码的商业库代码、受保密协议约束的代码AI 产出的复现抽查：
- 对 AI 产出的核心算法段，抽 1-2 处在代码托管平台搜索独特片段（一个不常见的注释句），确认非逐字复现。
- 提示端固定句式：「请给出原创实现，不要复现任何知名开源项目的代码；如实现与某开源实现相似请说明」。
- 排错：发现高度相似片段 → 查明其项目许可证；copyleft 家族 → 删除并重写，登记事件。
公式或模型
本节不适用：许可证义务是法律文本问题，工程侧只有流程规则，无数值模型。
图示
本节不适用：三步流程与政策表已表达完整，图示无增量。
直观类比
像食品进口：先看原产地标签（LICENSE 原文）、再对入境清单（政策表）、最后入海关台账（NOTICE 登记）——「看起来没问题」不能代替三道手续。
常见误区
- 只看 README 不看 LICENSE 文件：声明与实际许可证不一致的情形并不罕见。
- 「AI 写的没有许可证问题」：复现片段携带原项目义务；模型不产生许可是零假设而非保证。
- 例外处理不落档：审批过的例外必须有记录，否则换人即失忆、审计即事故。
与其他知识点的关系
kp-031 讨论训练数据版权争议的伦理面；kp-022 的核验流程在「存在性/健康度」之外应并入本节许可证项。
自测题
要点：宽松型（MIT/BSD/Apache-2.0）保留声明即可；著佐权型（GPL/AGPL）在分发或网络服务下要求开放衍生源码。
要点：按政策表上报决策人并登记例外，不自行放行——把法律判断交还给有决策权的人。
- 两大家族的代表许可证与义务差异？
- 面对无法判断的许可证情形，工程师的正确动作？
延伸阅读
各主流许可证官方文本（MIT / Apache-2.0 / GPL-3.0 / AGPL-3.0）——义务判断的唯一权威来源，建议通读一遍 MIT 与 Apache-2.0 全文。