LGPL 组件被审计出风险，如何核对链接方式、源码和依赖义务？

审计发现LGPL组件后，应先检查具体版本、使用方式和交付材料。以LGPL 2.1为例，动态链接并非自动消除许可义务，静态链接也不能直接推导为必须公开全部自有源码。

先分清“修改库”与“使用库”

如果修改了LGPL库，并对外分发相应代码或二进制，需要按许可证处理修改后的库、声明和对应源码。若自有程序只是使用该库，则继续审查第6节对组合分发的条件。两种情况可能同时存在，应分别记录。LGPL 2.1第2、4、6节

链接方式影响需要准备的材料

采用合适的共享库机制时，用户应能够用接口兼容的修改版库运行程序。“用了动态链接”只是起点，还要核对软件是否锁定库文件，以及许可和声明是否随交付物提供。

静态链接情形下，第6节包含提供库的对应源码，以及足以使用户修改库后重新链接程序的应用目标代码或源码等路径。重点是满足条款并验证重新链接结果，不能机械要求公开所有自有源码，也不能只交一份无法重建程序的文件包。

此外，分发条款应允许用户为自身使用进行相关修改，并为调试修改进行逆向工程；终端用户协议中的全面禁止条款需要核对。LGPL 3.0的术语与条件另有安排，不宜直接混用。LGPL 2.1原文

PDF 组件不能只看最外层许可

例如，Flying Saucer的公开分支说明自身采用LGPL 2.1或后续版本，并提示审查随附依赖。若实际项目引入iText 5，还应核对其AGPLv3或商业许可安排。外层库的LGPL标签不能覆盖底层依赖。Flying Saucer说明与iText官方许可说明

如何关闭这条审计问题

建议按顺序完成：锁定依赖版本和许可；记录是否修改；确认链接与分发方式；补齐声明、库源码和必要重建材料；实测替换或重新链接；由责任人复核留档。

如果业务无法履行相应义务，可以评估额外授权或替代方案。更换组件后仍需检查新依赖、功能兼容性和交付材料。工具适合发现对象与差异，不能代替具体授权条件的判断。