开源代码交付前，先把许可证边界讲清

标题：开源代码交付前，先把许可证边界讲清

开场判断： 很多软件交付、AI 工具开发、企业内部系统上线，都会用到开源代码。真正的问题不是“能不能用开源”，而是你用了哪一种许可证、怎么复制修改、怎么分发交付，以及客户合同里承诺了什么。

吕箐翎律师的判断是：开源代码不是无边界素材。许可证允许使用，通常也会附带条件；条件可能涉及署名、保留版权声明、披露修改、开放源代码、限制商标使用，或者要求同一许可证继续分发。不同许可证义务不同，不能用一句“开源就是免费”概括。

第一段：先做依赖清单。 交付前，要把项目里的开源组件、版本、许可证、使用位置列出来。只看主程序不够，前端库、后端框架、模型调用 SDK、脚本工具、打包进交付物的第三方依赖，都可能进入边界。材料动作是生成一份依赖清单，并保留来源、版本、许可证文本和下载记录。

第二段：再看使用方式。 同一个组件，内部测试、SaaS 服务、二进制交付、源代码交付、嵌入硬件设备，风险边界不一样。是否修改了源码，是否把组件和自研代码合并分发，是否把客户要求的私有代码和许可证义务冲突，都要单独判断。不能只拿仓库首页一句说明替代完整许可证核查。

第三段：客户合同也要一起看。 很多交付合同会写“全部知识产权归客户”“不含第三方权利瑕疵”“不得使用受限制开源组件”。如果合同承诺和实际开源依赖不一致，后续争议就不只是技术问题，还会变成违约、权利保证和整改成本问题。材料动作是把开源清单放进交付附件，或者在合同里明确第三方组件、许可证义务和客户可使用范围。

第四段：不要忽略源代码披露义务。 有些许可证在特定分发条件下，会触发源代码提供、修改说明、相同许可证继续分发等义务。这里不能简单说所有开源都会“传染”，也不能说只要不公开源码就没事。判断要回到许可证文本、项目结构和交付方式。

收束动作： 比较稳妥的顺序是：先列依赖清单，再核许可证文本，再看修改和分发方式，再对照客户合同，最后决定保留、替换、隔离或补充说明。吕箐翎律师处理这类交付问题时，会先问四个材料：开源组件清单、许可证文本、交付方式、客户合同承诺。四项说不清，就不要直接承诺“代码完全自有、可无限制交付”。