Impact of GraalVM native images compilation on LGPL-licensed libraries

Question

As far as I have understood, LGPL-licensed libraries must either be linked dynamically or there must be a mechanism to swap them out of the resulting work. See section 4d of the LGPL license.

Now in traditional Java tech stacks, everything is pretty much linked dynamically, which means there are no issues with LGPL. Comes in GraalVM with ahead-of-time compilation to create native images, essentially a way to compile Java programs statically (it performs inlining as one of its build steps and works under the closed-world-assumption).

For me it then seems that GraalVM thus either needs to implement some mechanisms to swap out the LGPL-licensed libraries of native images (which I have not found) or that the source code for native images needs to be distributed. However, the maintainers of a prominent LGPL library called Hibernate don't seem to identify any issues.

Are the folks at Hibernate turning a blind eye to encourage people using their library or did I miss something? Isn't there a compliance problem when using LGPL'ed libraries in GraalVM native images?

Answer 1

For me it then seems that GraalVM thus either needs to implement some mechanisms to swap out the LGPL-licensed libraries of native images (which I have not found) or that the source code for native images needs to be distributed.

The LGPL does not require that you can directly replace the LGPL-portion of an executable. It only requires that someone with the engineering skills and knowledge can re-create the executable with a modified LGPL part.

As GraalVM uses a JAR file as input to create the native image, people can already satisfy the LGPL requirements by providing a JAR file of their application in addition to the native executable from GraalVM.

The fact that you need to run the modified version through GraalVM again is not an issue for LGPL compliance.