An LGPL component is flagged in an audit: how to review linking, source and dependency obligations

After discovering an LGPL component through auditing, one should first check the specific version, usage method, and delivery materials. Using LGPL 2.1 as an example, dynamic linking does not automatically eliminate licensing obligations, nor is static linking a direct indication that all proprietary source code must be publicly disclosed.

First distinguish modifying from using a library

If you have modified an LGPL library and distributed its corresponding code or binary, you need to handle the modified library, declarations, and associated source code according to the license. If your own program merely uses this library, continue reviewing Section 6 for conditions of combined distribution. Both scenarios may coexist; they should be recorded separately.

The linking method determines the evidence required

When using appropriate shared library mechanisms, users should be able to run the program with a compatible modified version of the library. 'Dynamic linking' is just the starting point; one must also verify whether the software locks in the library files and whether licenses and declarations are provided along with the delivery materials.

In static linking scenarios, Section 6 requires providing the corresponding source code for the library, as well as application target code or source code sufficient to allow users to modify the library and re-link the program. The focus is on meeting the terms and validating the results of re-linking; it cannot be mechanically required to disclose all proprietary source codes, nor can only one file package that cannot rebuild the program be submitted.

Distribution terms should also allow users to make modifications for their own use and to reverse-engineer for debugging. Broad prohibitions in an end-user licence agreement therefore require review. LGPL 3.0 structures these conditions differently and should not be treated as interchangeable with LGPL 2.1. LGPL 2.1 licence text

A PDF component requires more than top-level licence review

For example, the public branch description of Flying Saucer indicates its use of LGPL 2.1 or a later version and prompts reviewers to check accompanying dependencies. If your actual project introduces iText 5, it should also verify whether it has an AGPLv3 license arrangement or a commercial licensing agreement. The LGPL tag on an outer library cannot cover the underlying dependencies. Flying Saucer description and iText official licensing explanation.

How to close the audit finding

It is recommended to follow these steps in order: lock the dependency version and license; record any modifications made; confirm that links are correct and distribution methods are appropriate; complete declarations, source code of libraries, and necessary rebuild materials; test replacements or re-link them; have the responsible party review and retain.

If business obligations cannot be fulfilled, additional authorizations or alternative solutions can be evaluated. After replacing components, it is still necessary to check new dependencies, functional compatibility, and delivery materials. Tools are suitable for discovering objects and differences but cannot replace the judgment of specific authorization conditions.