开源模型和开源代码嵌进AI产品，商用边界到底在哪——许可证传染、API义务与终止补救的三个实务判断

#引言：一份没有台账的技术栈

　　先说一个在AI产品公司里相当典型的场景。一家做企业知识库问答的公司，用一年多时间把产品做起来了：检索环节用了社区里一个成熟的开源框架，向量检索依赖一个开源客户端，生成环节接的是一个开源模型的权重，另外还有几个零散的工具库。产品按席位收费，客户数据留在客户自己的环境里，团队一直觉得自己"技术选型很干净"——毕竟用的都是开源的东西，没偷没抢。

　　直到A轮尽调，投资人问了一句：你们的开源合规清单在哪？法务这才去翻代码仓库，结果翻出四种不同的许可证：检索框架是Apache 2.0，向量库客户端是AGPL，一个底层工具库是GPLv3，模型权重则是发布方自己写的一份许可协议，条款和前面三个都不一样。四种许可证，四套义务，团队此前一套都没专门评估过。

　　这件事真正的难点，不在于"开源能不能商用"——能，这一点没有争议，开放源代码倡议组织（Open Source Initiative，OSI）的开源定义里就明确要求许可证不得歧视任何领域，包括商业用途。难点在于，"可以商用"和"商用没有条件"是两件完全不同的事。许可证给的是附条件的授权，条件没满足，授权就不成立；授权不成立，后面所有的复制、修改、分发就都失去了权利基础。下面三个判断，是这类项目里最容易判错、也最贵的三处。

#先摆正一个前提：开源不等于放弃著作权，也不等于"随便用"

　　很多团队的潜意识里，开源代码像是公共财物：既然挂在公开仓库里，谁都能下载，那用起来应该和用公开的标准文档差不多。这个类比在法律的第一个环节就断了。

　　《著作权法》第三条把计算机软件明确列为作品类型，现行文本为2020年11月11日第三次修正。《计算机软件保护条例》第八条则把软件著作权人的权利逐项列出，包括复制权、发行权、信息网络传播权、修改权等。也就是说，一段开源代码首先是一件受著作权保护的作品，权利人本来可以不放出来；他选择放出来，是通过许可证把一部分权利让渡给使用者，而不是把权利扔掉。

　　这一点在司法上已经有非常清楚的表达。广州知识产权法院审理的济宁市罗盒网络科技有限公司诉广州市玩友网络科技有限公司等侵害计算机软件著作权纠纷案，案号（2019）粤73知民初207号，2021年9月29日作出一审判决。判决书里有一段论述值得每个技术负责人读一遍，其核心意思是：开源软件以许可协议的方式授予使用人在遵守许可限制的条件下自由使用、复制、改编、再发布，法律基础是著作权许可；所谓"自由"，是通过著作权许可给予的自由，而不是自由得没有知识产权，权利人并未完全放弃著作权，仍可依许可协议寻求著作权保护。该案一审判决被告立即停止通过互联网提供含侵权代码的四款软件，并赔偿经济损失及维权合理开支共计50万元。

　　风险因此集中在三种误判上。第一种是把"能下载"当成"能商用"。实际上许可证恰恰是在商用这个环节上分叉最明显的地方：宽松型许可证基本不干涉你如何商用，传染型许可证则会把开源义务传导到你自己的代码上。第二种是把"开源"当成"无主"，于是既不保留版权声明，也不记录版本来源，等到需要证明"我用的是哪个版本、从哪来的"时，什么都拿不出来。第三种最常见，是把"我们改了但没对外发布"当成"没有义务"——这一点要分情况，内部自用和对外提供，法律后果差别很大，下一节会展开。

　　从律师视角看，第一件该做的事不是读许可证，而是建台账。哪些组件、什么版本、什么许可证、用在哪个模块、是直接依赖还是传递依赖、有没有修改过、以什么形态对外提供——这几列填不出来，后面所有的合规判断都是空谈。台账的价值不只是应付尽调，它同时也是争议发生时的第一份证据。

#一、传染性到底传到哪里：独立程序还是衍生作品

　　这是整篇里技术性最强、也最容易两边都判错的一节。

　　先看规则。GPLv3（GNU通用公共许可协议第三版）第5条c项要求，基于本程序的作品必须以本许可证对整个作品授权，"无论它们是如何打包的"；第6条进一步规定，以目标代码形式传播时，必须一并提供机器可读的对应源代码。这两条合起来，就是大家常说的"传染性"。

　　但传染性不是无条件的。同一个判决里，法院把边界讲得比很多科普文章都清楚。判决原文的表述是：如果能够确定作品的一部分并非程序的衍生产品，与程序并未混合在一起，也未意图在某种存储或分发媒介上组成一个更大的程序，而是独立的、属不同的作品，那么这部分独立程序发布时可以不受GPL约束；但一旦把它作为程序整体的一部分发布，就会受GPL约束。判决还专门举了安卓的例子——把GPL的适用局限在底层内核，上层类库和应用框架适用较宽松的许可证，从而避免传染整个系统；并提示，若无法回避许可证冲突，应当采取简单的编程接口连接，降低源代码运行时的融合程度。

　　这条边界在实际案件里是怎么落地的？该案被告主张，被诉软件里只有"沙盒分身"这一块用了原告的代码，其余部分是自研的。法院的处理是：沙盒分身功能代码是作为被诉软件的衍生部分而整体发布的，被告没有举证证明这部分是独立的，也没有采用类似安卓那样的分层隔离方法，因此认定被诉软件应整体适用GPLv3，被告应开源整个被诉软件的源代码。

　　请注意这个举证结构：说"这部分是独立的"很容易，证明它独立很难。法院要看的不是你的架构图，而是构建记录、进程边界、通信方式、发布形态这些能被验证的东西。这也解释了为什么很多团队在事后才想起来"我们其实是微服务架构"——说得再对，拿不出证据也没用。

　　实务里两种极端误判都很常见。一种是一听到GPL就恐慌，认为"只要引入一行GPL代码，整个产品都得开源"，于是要么放弃合理的组件选型，要么花大价钱买并不需要的商业授权。另一种正好相反，认为"我们只是调用，没改它的代码"，于是把一个以库形式链接进主程序的GPL组件当成了普通依赖。这两种判断都跳过了同一个步骤：看融合程度。

　　路径比较上，企业其实只有三条路，代价差别很大。第一条是架构隔离，把传染型组件放在独立进程或独立服务里，通过接口通信，并且让这个服务本身也以合规方式开源——前期改造成本高，但一旦做成，后续可以长期沿用。第二条是购买商业授权，很多采取双许可模式的项目会提供闭源商用授权，钱花得明白，但要注意授权范围（席位、部署形态、是否含二次分发）常常比想象中窄。第三条是全量开源，把包含该组件的整个作品按GPL发布——听着最省事，实际上对绝大多数商业产品不可行，因为它等于把核心代码公开，而且已经发布的版本收不回来。选择哪条，取决于这个组件在产品里的位置：是可有可无的工具，还是不可替代的核心。前者换掉最便宜，后者才值得谈授权。

#二、只提供API、不分发软件，义务就没了吗

　　这一节针对的是SaaS形态，也就是这几年AI产品最主流的交付方式：代码跑在厂商自己的服务器上，客户通过网页或接口调用，从不下载安装包。

　　GPLv3的定义部分给了一个关键区分。"传播"（propagate）指任何在未经许可时会让你承担侵权责任的行为，但排除"在计算机上运行程序"和"修改私人副本"；"传递"（convey）指任何使其他方能够制作或接收副本的传播，而"仅通过计算机网络与用户交互、不传输副本"不构成传递。按这个定义，纯SaaS模式下不向用户交付副本，通常不会触发第6条的源代码提供义务。很多团队就是靠这一条安心下来的。

　　AGPLv3恰恰是为堵这个缺口而生的。它的第13条（Remote Network Interaction）规定：如果你修改了本程序，你修改后的版本必须向所有通过计算机网络与它远程交互的用户，显著地提供获取其对应源代码的机会，方式是从网络服务器免费提供，且通过某种标准或惯常的便于复制软件的手段。换句话说，AGPL把"提供服务"这件事本身，当成了触发源代码义务的开关——但请注意，条文的前提是"如果你修改了本程序"。没有修改、只是原样部署，第13条的义务并不当然产生；当然，一旦涉及对外传递副本，第4条至第6条那套规则仍然适用。

　　风险因此有两个高频形态。第一种是"改了但没意识到要提供源码"：团队为了适配业务，把AGPL组件的检索逻辑、缓存策略、鉴权流程都动过，对外提供网络服务，却没有任何获取源码的入口。这类改动在代码评审里往往被当成"配置调整"，但在许可证语境下，改代码和改配置是两回事。第二种更隐蔽：前端把AGPL库打包进浏览器端脚本，用户一打开页面就下载了这份代码——这就不是"仅网络交互"了，而是实打实的副本传递，第6条的义务直接落下来。

　　还有一层容易被忽略：企业内部的修改自用，规则其实相对宽松。《计算机软件保护条例》第十六条允许合法复制品所有人为把软件用于实际的计算机应用环境或者改进其功能、性能而进行必要的修改，但除合同另有约定外，未经软件著作权人许可，不得向第三方提供修改后的软件。这一条给了内部自用一定空间，但它管的是著作权法层面的默认规则，管不了许可证——许可证是权利人自己设定的条件，条件更严就得按条件来。这也是为什么"我们自己用，不出去"这句话，在开源合规里只能算半个答案。

　　落地动作上，最有效的不是逐个人工看代码，而是把依赖树扫出来。开源组件的传递依赖往往比直接依赖更多，一个不起眼的间接引入，可能把传染型许可证带进主程序。扫描之后再做两件事：一是把"修改"和"配置"分开记录，凡是动过源码的组件单独标记；二是按交付形态分类——随安装包分发、随前端脚本下发、仅服务端运行，三种形态对应三套义务，不能混着评估。至于AGPL组件，如果业务上确实离不开，商业授权、替换组件、把它隔离成不修改的独立服务，是三条现实路径，各自的成本需要在架构阶段就算清楚，而不是等产品上线后再补。

#三、许可证被终止之后，还有没有补救窗口

　　前面两节讨论的是"要不要遵守"，这一节讨论的是"没遵守之后会怎样"，这是很多企业真正吃亏的地方。

　　GPLv3第8条写得毫不含糊：除本许可证明确授权外，你不得传播或修改受保护作品，任何其他传播或修改的企图都是无效的，并将自动终止你通过本许可证获得的权利。这句话的杀伤力在于"自动"——不需要权利人发函，不需要任何程序，违约事实成立的那一刻，授权就没了。而授权一旦没了，后续所有的复制、修改、分发都失去权利基础，性质从违约转为侵权。

　　但第8条同时留了窗口。如果你停止一切违约行为，许可会临时恢复；如果版权人在你停止违约后60天内没有以某种合理方式通知你违约，则永久恢复。这个60天条款是实务中最有价值的谈判筹码，也是最容易被浪费的——很多企业收到律师函后的第一反应是"先改代码，改完再谈"，却既不记录停止违约的时间点，也不保留整改过程的证据，等到要主张"我已经在60天内停止"时，拿不出任何可验证的材料。

　　另一条不能忽略的规则，是许可证的不可撤回性。同一个判决里，法院认定：只要某个软件版本加入了GPLv3，就无法随意删除该协议，该版本源代码将永久保持开源，即使授权方事后删除协议也没有回溯力，授权方只能在后续版本中变更或删除，但不影响此前版本继续适用GPLv3的效力。这条对两类人都有约束：对使用者，意味着"我用的那个版本"永远受当时许可证约束，不能指望上游改协议来解套；对以开源起家的公司，意味着想靠"先开源后闭源"完成商业转型，法律上走不通，只能靠新版本重新起算。

　　路径比较上，收到主张后的选择其实只有两类。一类是立即停止、书面确认、按许可证要求补齐义务，再谈后续合作或补授权。这条路的代价是短期业务中断和改造成本，但能保住第8条的恢复机制，也最容易把赔偿谈到可控区间。另一类是对抗，主张自己不构成衍生作品、或对方无权主张。这条路不是不能走——前面说过，独立程序的抗辩在法理上是成立的——但它要求你在架构和证据上真的站得住，而且一旦败诉，赔偿基数是按《著作权法》第五十四条算的：实际损失或违法所得，难以计算的参照权利使用费；故意侵权且情节严重的，可以按上述方法确定数额的一倍以上五倍以下赔偿；全都难以计算的，由法院在五百元以上五百万元以下酌定，另加合理开支。对一家正在融资或准备上市的公司，这个不确定性本身就是成本。

　　还有一个采购侧的风险，值得单独提醒。《计算机软件保护条例》第三十条规定，软件的复制品持有人不知道也没有合理理由应当知道该软件是侵权复制品的，不承担赔偿责任，但应当停止使用、销毁该侵权复制品；如果停止使用并销毁会带来重大损失，使用人可以在向著作权人支付合理费用后继续使用。这条常被理解成"善意使用人免责"，但它免的只是赔偿责任，停用和销毁的义务照旧。也就是说，你从供应商那里买来一个打包了侵权组件的产品，即便完全不知情，产品也可能要下架。这正是采购合同里必须写清知识产权陈述保证和赔偿条款的原因——不是为了打官司，而是为了在出事时有人分担。

#四、律师落地：把开源合规做成一条能跑的流程

　　把上面三个判断收拢成动作，其实是一套并不复杂的流程，难的是让它常态运行，而不是尽调前突击一周。

　　立项阶段，先做许可证画像：这个产品是分发形态、SaaS形态，还是混合形态？核心模块能不能接受传染型许可证？如果答案是"不能"，那么在技术选型时就要把GPL、AGPL类组件排除在外，而不是等写完了再改。这一步的产出应该是一张明确的白名单，而不是一句"尽量用宽松的"。

　　开发阶段，依赖扫描要进CI，每次合并都跑一遍，新增的传递依赖必须触发人工确认。同时建立修改台账：哪些组件的源码被动过、动在哪里、为什么动。这份台账在判断"是否构成修改"时是直接证据，事后补是补不出来的。

　　交付阶段，按形态配置义务：随安装包分发的，附许可证副本、保留版权与归属声明、按需提供对应源代码；前端打包的，同样按分发处理；纯服务端运行的，评估是否落入AGPL第13条，并准备好源码获取入口。这一套动作最好做成发布检查项，和人力的代码评审绑在一起，而不是靠法务在发布前抽查。

　　采购与外包阶段，把开源合规写进合同：供方须披露产品中包含的开源组件及许可证类型，承诺已履行相关义务，并对因开源许可瑕疵导致的索赔承担赔偿；同时约定交付物中不得包含特定类型的许可证组件。对外投资或并购场景下，这套材料还要能支撑尽调——投资人问的往往不是"你有没有开源组件"，而是"你能不能证明你合规"。

　　最后是人的问题。开源合规出问题，绝大多数不是因为有人故意违规，而是因为没人负责。指定一个 owner，哪怕是兼职，让他在新增依赖时有否决权，比写十页制度都管用。

#结语

　　开源这套机制的精妙之处，在于它用著作权许可换来了协作，而不是放弃了著作权。理解这一点，很多判断就顺了：能不能商用，取决于许可证有没有歧视领域；要不要开源自己的代码，取决于融合程度和交付形态；违约之后还有没有退路，取决于你有没有在第8条那个窗口里做对动作。这三个问题的答案都不在"开源"这两个字里，而在具体那一份许可证的条款里，以及你留下的那些记录里。

　　如果你正在把开源模型和开源组件拼成对外收费的产品，或者正准备融资、被投、被收购，建议在提交材料之前先把许可证台账和技术架构对一遍——这件事越早做越便宜。

需要梳理开源许可证义务、评估传染性范围或处理许可终止后的补救？欢迎预约测绘，我们可以帮你把这条链路一次理清。