Distributing native-images with quarkus extension which use LGPL licensed dependencies

[ls-bit]

Hi,

we are using the quarkus mariadb extension, which uses a LGPL licensed jdbc driver https://mvnrepository.com/artifact/org.mariadb.jdbc/mariadb-java-client.

We are wondering how to comply with the LGPL requirements (allowing users to modify/replace the library, dynamically linking the library or providing object files for static linking) when commercially distributing native binaries which use the mariadb extension? Distributing the proprietary source code is not an option for us..

Is there any guidance or does anyone have experience with how to comply with the LGPL for such cases with native images?

Thanks

---

Related references
https://mariadb.com/docs/general-resources/community/community/faq/licensing-questions/licensing-faq
https://hibernate.org/community/license/

[cescoffier]

\CC @maxandersen @Sanne

[Sanne]

Hello,
there are two different aspects intertwined in your question.

One aspect is the legal question about this being in fact necessary - which I can't answer as I'm not a lawyer, and most importantly I'm not your lawyer: I've seen different legal opinions on the matter, in particular about the fact that a library needs to be able to being replaced as a drop-in. Clearly the language used in the LGPL license predates such compilation techniques, so there's unfortunately some ambiguity.

The other aspect is perhaps more practical - how can anyone consuming your native image swap a dependency? Now again this depends on legal assumptions of what your undersanding is of the requirements and I'm not going to comment about this being necessary, but hypotethically if you wanted to offer some forms of rebuilding to your consumers, there are several ways in which you can provide a rebuild-friendly set of artifacts which don't include your sources, and have not been compiled into a single native-image yet.

• https://quarkus.io/guides/reaugmentation

My personal view on the matter - and absolutely not legal advice - is to realize that such aspects have already been a bit hazy since the JVM's inception: within a running JVM, the "compiled code" generated at runtime is often mixing code which has been loaded from a variety of different libraries, ignoring licensing boundaries. This implies that there's a generally accepted understanding that the applicability of such restrictions depends on the context, quite often related on the phase of building / assembling.

Incidentally, you happen to link to the Hibernate license page - I wrote some of that page myself, and indeed the intent of that page was to clarify that the intent of the maintainers matter and that we believe you're fine to use them in such contexts. Clearly these are OSS, java libraries: they are being distributed with the explicit intent to allow people to use them on the JVM.

[Sanne]

another pointer: hibernate/hibernate.org@a56a03f

[ls-bit]

Thank you very much for the insights and your perspective on this!