相关裁判及公开来源
-
北京某电子商务有限公司诉北京某信息技术有限公司侵害计算机软件著作权纠纷案
裁判案号：（2016）京73民初1111号；（2019）最高法知民终663号
法院：最高人民法院
最高人民法院二审民事判决；公开案例库材料2023-13-2-158-007列明审级及案号，并非裁判全文。
查看公开来源 ↗
指导性案例编号、案例库入库编号与裁判案号分别列示。
快速结论
“开源可以商用”不能替代许可证条件审查。笔者认为，合规重点是组件来源、版本、修改情况及对外提供方式，收费与否只是事实之一；使用开源代码也不等于可以任意去掉声明。
程序规则为什么重要
最高法有关GPL前后端争议的入库案例，考察技术功能、封装和部署，说明数据通信不自动使程序成为不可分割整体。但服务器分开、项目目录分开等表面形式，也不能保证软件在许可证意义上必然独立。
（2019）最高法知民终663号中，权利人明确不以前端代码主张权利，只主张后端。法院结合前后端展示方式、所用技术、功能分工以及可独立打包部署等事实，认定后端属于与前端联合的独立程序，不因前端采用GPL代码而被强制开源，驳回复制后端一方的抗辩。该结论以本案程序的实际独立性为前提，不是“前端”“后端”的命名本身产生许可豁免；声称对方应开源也不能替代证明自身复制行为获得许可。
企业应记录复制了哪些代码、是否修改、如何连接，以及实际交付给客户什么内容。通过通信协议关联的独立程序，与把组件代码编入一个程序，可能涉及不同分析。GPL与AGPL、不同版本及商业双重许可，应分别核对。
笔者观点：把合规嵌入构建记录
建议组件清单同时记录下载出处、哈希、许可文本和负责人。每次发布保留构建配置与交付包清单，避免最后只剩口头说明。源代码提供义务、声明保留和许可兼容性，应逐项检查，不用一份笼统承诺解决。
收购软件或委托开发时，要求交付第三方组件清单和权利保证，明确整改责任。供应商说“代码由我们开发”，不能证明未使用第三方组件。出现合规问题后，可以评估替换、取得商用许可或按条件履行义务，选择取决于架构和合同。
哪些结论不能从案例直接推出
该案不说明所有后端都可以闭源，也不说明云服务永远无源码义务。开源许可争议还可能涉及合同与著作权路径，具体请求和责任分别分析。对安全扫描发现的许可证结果，应人工核对真正使用的文件和版本，避免把仓库中未进入产品的材料直接当作发布组件。
笔者建议：应用与核验
实际发布审查可以随机选一个交付包，核对清单、许可证声明与真实文件是否一致。构建过程从网络临时下载的组件，尤其需要锁定版本与出处；客户最终交付包应直接核验组件清单、许可证声明与实际文件。
在采购与交付合同中，可说明源码、第三方组件和商用许可由谁负责。即使开源义务不要求交付某段独立代码，合同仍可能约定必须交付。反过来，客户合同未提开源，也不能免除实际许可证义务，两层责任需要分别管理。
核对来源与适用时点
案例入库编号2023-13-2-158-007。软件许可证合规评估应依据实际版本的许可证文本、代码关系和完整发布方式开展。