Every external library FL5 uses under the LGPL is delivered as a shared library (.so, .dll) in the program directory, never linked statically into the FL5 binaries, so that it can be replaced. Libraries under other licenses may be linked statically and are not covered here.
To replace one, either delete it in the program directory when the replacement is already on the library path, or overwrite it in the program directory. The replacement has to fulfil the same interface, which in practice means the same major version of the same library.
In all cases we recommend using the tested and supported libraries from this package. If a supplied library is replaced, the license terms and warranty of the new library become valid, replacing the license and warranty of the replaced library. In particular, FL5 itself is then no longer covered by our warranty, because we can no longer say which code it runs against.
THE THREE ZLIB IMPLEMENTATIONS:
The zlib compression interface is provided by more than one implementation, and which one is active depends on the platform. This matters for reading the SBOM and the CVE reports, so it is stated here rather than left to be inferred.
zlib-ng is used wherever it can be built, because it is markedly faster and is a drop-in replacement: it provides the zlib interface, and the zlib version it reports is the interface level it implements, not a zlib release. Where zlib-ng cannot be built, the original zlib is used instead, with no difference in behaviour.
On z/OS and USS the extended zlib of IBM is used, which supports the zEDC hardware compression of the platform. It is part of the operating system and is maintained by IBM, so it is a prerequisite rather than something we deliver. Where zEDC is unavailable and no Language Environment is at hand, FL5 falls back to its own build of the original zlib.
For the SBOM and for vulnerability tracking, zlib and zlib-ng are therefore carried as two separate components with their own versions, their own licenses and their own advisories -- they are separate projects, and a vulnerability in one is not a vulnerability in the other. IBM's zlib is not tracked by us at all: as part of the operating system it is covered by IBM's own maintenance, in the same way as the C runtime library.