案例研究｜使用GPL前端，独立后端是否必须一起开源

快速结论

前端使用GPL组件，不当然使独立的后端适用同一开源义务；关键在程序关系和许可证条件。

事实与裁判结果

北京某电子商务公司起诉某信息技术公司复制其网站软件。被告抗辩：原告前端使用GPL代码，前后端存在交互，整个系统应当视为前端的修订版本并向第三方开源。原告则明确放弃以前端代码主张权利，仅以后端代码作为本案权利软件。这项请求范围的限定，是理解裁判的关键事实。

北京知识产权法院于2019年7月5日作出（2016）京73民初1111号判决，判令停止侵权，赔偿经济损失25万元及合理支出3万元，并在网站首页刊登声明消除影响。最高法于2019年12月23日作出（2019）最高法知民终663号判决，驳回上诉、维持原判。案件并非抽象确认某类后端永久无需开源，而是在本案软件结构、许可内容和主张范围内，否定了被告复制后端代码的抗辩。官方入库文本。

法院认为

法院考察展示方式、所用技术、功能分工以及分别打包、部署的可能性，认定本案前后端是相互独立但有联合关系的程序。依涉案GPL条款，许可范围包括受保护程序以及其衍生程序、修订版本，不包括仅通过数据交换等方式联合的其他独立程序。因原告仅就独立后端主张权利，前端的GPL条件不能直接推出后端也受同样约束。

这一结论没有把“能够单独部署”设为唯一判断标准，也没有确认所有网络调用都不产生许可义务。需要结合实际代码是否复制、如何连接、修改与发布，以及具体版本的许可条款作判断。开源许可允许什么使用，与被告是否遵守许可条件、是否有权复制特定代码，是连续但不同的问题。

审判规则总结

1. 固定适用许可证及组件版本。
2. 分析复制、修改、连接、部署与发布的真实方式。
3. 区分独立软件通信与许可证针对衍生或组合程序提出的要求。

笔者观点与实务建议

笔者建议企业制作软件组件清单，同时记录每个组件的许可、修改状态及对外交付方式。销售人员口中的“前后端分离”只描述产品结构，不能直接证明法律上的独立程序。

对后端闭源安排，应保留架构图、构建文件、依赖关系和部署记录，以便解释程序规则。若实际静态链接、复制了组件代码或形成整体程序，则不能只凭服务器分开部署主张独立。SaaS还可能涉及AGPL的网络使用条款，不能拿GPL案件直接说明所有云服务均无源码义务。商用授权和开源授权并存时，也应核对选择的路径及对应证据。

争议中可将产品商业范围与程序技术判断标准画在不同图上。商业上作为一个系统销售，并不必然技术上属于一个程序；相反，不同安装包也可能包含同一受许可约束的代码。应由依赖、调用和代码使用事实解释，避免靠部署名词替代。

许可证扫描结果只是起点。还应核对原始仓库的版本及许可变更，确认对外发布包实际包含什么。客户需要源码的合同承诺，可能独立于开源义务成立，不能因本案结论就否认合同交付责任。

规则时点与实务要点

官方入库编号为2023-13-2-158-007。后端能否闭源，应结合代码关系、部署方式、GPL或AGPL版本及具体许可证条件审查。

公开来源

• 官方来源1