商业软件使用 MySQL，哪些情况下需要审查自有代码的开源义务？

商业软件使用MySQL，并不因为“商业”二字就必须公开全部自有代码。审查应分别看数据库服务器、客户端库或连接器，以及它们如何进入最终交付物。内部部署与对外组合分发，也不是同一种使用行为。

先确认自己取得了什么授权

Oracle公开提供MySQL的GPL与商业许可安排，并提示使用者查看具体下载包的许可说明。商业许可应按合同覆盖的软件、主体、用途和分发范围判断，不能推断一份采购合同自动解决全部第三方组件问题。MySQL官方许可说明

使用社区发行版时，保存精确版本、下载来源、LICENSE和相关例外文本。仅写“MySQL 8”或“官方驱动”，通常不足以完成审查。

区分三个常见场景

仅在组织内部运行。没有向外部交付程序副本时，与对外分发相比，GPL分析的事实基础不同。集团公司、外包团队或客户环境是否属于同一内部范围，需要按实际法律关系确认。

独立应用连接数据库服务。需要检查应用是否带入GPL客户端代码，以及应用和数据库的实际组合关系。通信使用socket或网络协议，只是技术事实，不能单独作为免除许可义务的结论。

随产品交付数据库或连接器。需进一步判断是独立聚合还是组合程序，并履行被分发组件自身的许可与源码义务。不能从“安装包内有MySQL”直接推导全部自有代码的处理方式。GPLv2第2、3节

FOSS Exception 不是闭源通行证

Oracle现行Universal FOSS Exception有明确的对象和条件，涉及符合定义的自由开源软件及对应源码。它不能作为任何闭源应用自由嵌入客户端库的通用授权。部分旧版本仍可能适用历史例外，必须以实际发行包为准。例外原文与旧例外说明

项目应交付一份什么样的审查材料

建议记录数据库和驱动版本、许可文件、是否修改、链接与部署方式、实际分发对象，以及计划提供的版权和源码材料。发现义务与商业目标冲突时，可评估合适的商业授权或替代组件；更换驱动之后仍要检查新驱动及其依赖。

软件成分分析可以帮助盘点这些对象，最终是否需要调整自有代码的发布方式，应基于具体组合事实与授权条款作判断。