夜雨聆风文｜吴卫勇律师【吴用无畏：吴用的智慧，无畏的勇气】
声明：本文案例基于本人经手的真实案件，为保护当事人隐私，已对行业、地点、情节、金额等信息做脱敏处理，请勿对号入座。
引子
“我们的餐饮SaaS系统，从点餐到供应链、支付到会员分期，前后投入了两年、近千万研发费用。可就在准备大规模推广时，收到一封律师函：说我们使用了GPL协议的开源代码，没有按照协议开源全部代码，要求我们限期公开，否则将面临侵权诉讼。”
客户是一家杭州的互联网技术公司，创始人老李是技术出身，做过医疗软件、教培软件，也开发过餐饮点餐系统。这一次，他决心做一个“大而全”的餐饮全流程软件——从点餐、后厨管理、供应链采购、支付结算，到会员消费分期。他带着团队奋战两年，产品接近成熟。
可这封律师函，像一盆冷水浇下来。开源代码是程序员的“日常工具”，怎么就成了“定时炸弹”？
商业背景
该企业位于杭州，主要从事餐饮行业SaaS软件研发。创始人老李是资深程序员，曾独立开发过多款医疗、教培、餐饮软件。这一次，他看准了餐饮全流程管理的市场机会，决心打造一款集点餐、供应链、支付、会员分期于一体的一站式系统。
产品采用前后端分离架构，前端使用React框架（MIT许可证），后端使用Spring Boot（Apache 2.0许可证）。在开发过程中，为了提高效率，团队在数据处理模块中引用了一段开源代码，该代码来源于GitHub上一个“数据处理工具库”，其许可证为GPL 3.0。
团队在使用时，并未仔细阅读许可证条款，直接将代码整合进产品核心模块。产品开发完成后，公司申请了软件著作权，并开始向餐饮企业推广。某知名开源组织在审计时发现该产品使用了GPL代码但未开源，遂委托律师发函，要求公司公开全部源代码。
法律困境
本案的核心问题是：使用了GPL协议的开源代码，是否必须公开全部源代码？
GPL（GNU General Public License）是一种“强传染性”的开源许可证。其核心条款是：任何基于GPL代码的衍生作品，在分发时，必须同样采用GPL协议，并公开全部源代码。
也就是说，如果公司仅仅是内部使用，不对外分发，可以不公开。但一旦产品对外销售或提供服务（SaaS模式是否属于“分发”存在争议，但GPL 3.0明确将“通过网络提供交互式服务”视为“conveying”），则需公开。
本案中，公司产品是商业SaaS系统，对外收取服务费，显然属于“分发”范畴。而技术团队直接将GPL代码整合进核心模块，未做隔离，导致整个软件可能被视为“衍生作品”，从而触发“传染”条款。需要特别提示的是，如果使用的是AGPL协议（GPL的SaaS强化版），则即使产品以云服务形式提供，也强制要求公开全部源代码，风险更高。
公司面临两难：
公开源码：核心算法、业务流程、分期风控模型等商业秘密将全部暴露，竞争对手可以轻易复制。
不公开：面临侵权诉讼，可能被禁止继续使用该代码，甚至被要求删除、赔偿，产品无法继续销售。
法商策略
我们制定了四条应对路径。
第一路径：技术隔离——判断GPL代码与公司核心代码的关联性。
我们委托技术专家对代码库进行审查，分析GPL代码的使用方式：
是直接复制到核心模块，还是通过独立进程调用？
是否修改了GPL代码？是否与公司代码紧密耦合？
是否有替换方案？
经审查，该段GPL代码仅为数据处理工具中的一个函数，公司对其进行了少量修改，且直接嵌入核心模块。技术专家认为，该使用方式属于“紧密耦合”，很可能被视为衍生作品。
第二路径：法律抗辩——主张“独立作品”例外。
根据GPL协议，如果将GPL代码作为“独立且分离的模块”与主程序通信，而不是直接合并，可以不触发传染。但本案中代码已直接嵌入，抗辩空间很小。
第三路径：商业谈判——主动公开部分代码，争取宽限。
我们建议公司主动联系开源组织，承认疏忽，并承诺在规定期限内整改。同时，提出以下方案：
将GPL代码替换为同等功能的MIT/BSD许可代码（重写或寻找替代库）。
在彻底替换前，暂时将涉及GPL代码的模块从产品中剥离，不影响其他功能。
向开源组织出具书面整改时间表，争取对方不提起诉讼。
第四路径：长期合规——采用“双许可证”策略，从源头规避风险。
双许可证策略是技术企业隔离风险的成熟做法。具体包括：
内核与外部分离：将核心商业代码（算法、风控模型、业务流程）采用商业许可证（闭源），仅允许内部使用。将通用功能、基础组件采用MIT、BSD等宽松许可证开源，形成“外层开源、内核闭源”的架构。
动态链接隔离：如果必须使用GPL代码，应将其作为独立进程运行，通过API或RPC与主程序通信，避免静态链接或直接嵌入。这种“独立且分离”的方式，在司法实践中可能被认定为不构成衍生作品。
双许可证发布：对于部分可对外公开的功能模块，可同时提供GPL和商业许可两种授权方式。用户可以选择购买商业许可免除开源义务，也可以使用GPL版本但需公开其衍生产品代码。
在本案中，我们建议公司未来重构架构，将核心算法和数据处理逻辑设计为独立的微服务，通过API调用。同时，对通用工具库采用MIT许可证发布，彻底切断GPL传染风险。
关键动作
立即替换GPL代码：组织技术团队，用一周时间（团队加班赶工，通宵测试，最终成功移植）重写该数据处理函数，并找到MIT协议的替代库，完成替换。
代码库审计：对整个项目进行全面开源合规审计，排查是否存在其他风险。
建立开源合规制度：制定公司《开源代码使用管理制度》，要求所有引入的开源代码必须经过合规审查，登记许可证信息，并建立“白名单”。
对外签署和解协议：向开源组织发函说明已替换代码，承诺未来合规。双方签署了《和解协议》，对方出具书面谅解声明，撤回律师函，不再追究历史责任。
最终结果
经过三周整改，公司完成了代码替换，并通过了内部合规审计。产品继续推向市场，未再收到侵权投诉。
创始人老李感慨：“以前觉得开源代码随便用，没想到还有这么多门道。要不是你们及时出手，我们可能真的要被逼公开全部源码，那两年心血就白费了。”
办完这个案子，我最大的感受
第一，开源不是“免费午餐”，许可证是“法律合同”。 使用开源代码，必须遵守其许可证条款。GPL是“强传染”的，AGPL更强，只要你的代码与它“结合”，就可能被“感染”。
第二，技术团队要有“开源合规意识”。 很多程序员只管“拿来用”，不管“怎么用”。公司应建立开源代码审批流程，严禁随意引入GPL、AGPL等强传染代码。
第三，SaaS模式并非“避风港”。 GPL 3.0已明确将SaaS纳入约束，AGPL更是专门针对云服务设计，风险依然存在。
第四，及时整改比消极应诉更有利。 本案中，公司主动承认问题、迅速整改，赢得了对方的谅解并签署了和解协议。如果硬扛，诉讼成本、商誉损失、产品停摆的风险都不可控。
如果你不想因为用了开源代码而被要求公开全部核心源码，你应该做五件事：
1. 建立开源代码“白名单”制度：明确只允许使用MIT、BSD、Apache 2.0等宽松许可证的开源代码，禁止引入GPL、AGPL等强传染代码。
2. 进行代码合规审查，排查许可风险：在产品发布前，使用自动化工具（如FOSSA、Black Duck）对代码库进行扫描，排查许可证风险。
3. 培训技术人员“看协议，后使用”习惯：让每个开发人员了解常见开源许可证的区别和风险，养成“先看协议再使用”的习惯。
4. 合同条款约束外包团队，确认合规：如果存在外包开发，合同中应明确要求不得引入不合规的开源代码，并约定违约责任。
5. 实施双许可证策略，核心或通用分别对策：对核心商业代码采用闭源许可，对外接口或通用组件采用MIT/BSD等宽松许可。如需使用GPL代码，必须严格隔离（独立进程、RPC调用），避免直接嵌入。
开源不是免费，合规始于架构。你现在的代码库，经得起审计吗？
全文完，本文作者：吴卫勇律师
更多讲解，在视频号「吴用无畏」
