3

In my company, we have a library that makes use of a 3rd party library with an LGPL3 license.

Although our library does not extend or modify any of the 3rd party library's code, it provides some implementations for behaviour customization

  • The 3rd party library allows this customization, and this is done using Java's ServiceLoader, where the library loads some custom implementation if it exists, else it will default to its own implementation

One of our worries about Java's ServiceLoader usage, is that there is no guarantee that our custom implementation will be the only one existing in the application's classpath, and therefore we can't guarantee that our implementation will be loaded

  • If an application that uses our library also needs the 3rd party library for their own custom work, our custom implementation may be wrongly loaded for that application, or vice-versa, our library may load a custom implementation that will break our expected behaviour

To work around this, we thought of repackaging the Java packages of the library

  • I'm speaking about java packages, and not repackaging a means of distribution
  • For example, the application base package is org.third.party and our idea was to repackage the library so that its base package would be something like repackaged.org.third.party
    • Similar to what jersey has done with guava, as they repackage it internally
    • Not sure if they modify any of guava's code, but guava has an Apache 2 License
  • This would be done using maven-shade-plugin with the relocate option

With this change we could ensure that our library implementation wouldn't "clash" with other custom implementations, because the repackaged library would be looking for an implementation under repackaged.org.third.party instead of org.third.party.

So, our doubt here is if this is allowed by the LGPL3 license. If so, what do we need to do to ensure compliance with the license?

  • Although we are not explicitly extending and modifying the 3rd party library source code, this repackaging could be seen as code changes, since the repackaged library would have its Java package declarations and inner imports also changed
  • According to the license, if any code change occurs, the source code must be made available - how should this be done? Should the source code be packaged together with the library, or it's only needed to make it available together with the repackaged library in a maven repository for example?

I tried searching StackOverflow/StackExchange for a similar question, but usually, the repackage that other LGPL posts refer to is related only to redistribution, or users are explicitly modifying the source code.

Improve this question

1 Answer 1

Reset to default
2

The intention of the LGPLv3 license is that the users of your library are allowed and able to

  • recreate the JAR file you provided
  • make improvements to the dependency
  • use their version of the JAR file instead of the one you provided

To meet the requirements of the LGPLv3, you should publish what you used as input (which version of which library) and how you created the re-packaged JAR file

Improve this answer
4
  • Thank you for your reply @bart-van-ingen-schenau. The "conditions" you mentioned should be met by providing the source code (so users can recreate, modify it and generate a new JAR file if needed). But does this source code need to be publicly available, or only available to all the recipients of my library? Also, you mentioned that we should publish how we created the re-package: is enough to have this information on the JAR's META-INF?
    – Gilberto Matos
    Mar 21 at 8:43
  • @GilbertoMatos, you only ever need to provide source code and/or build instructions to the people that (could) have received your software. So, you only need to provide it to the general public if your software is available to the general public.
    – Bart van Ingen Schenau
    Mar 21 at 10:40
  • Regarding having the re-packaging information in the JAR's META_INF, I am not a lawyer nor a Java developer, so I could be wrong here, but I would not find that good enough. But a short paragraph in a README or some other documentation file that describes the re-packaging in a way that a competent Java developer can understand and replicate it should suffice. Think about how you would describe it for the next maintainer of your software.
    – Bart van Ingen Schenau
    Mar 21 at 10:44
  • I see, makes sense. Anyway, as a developer, it's always a good practice to document such steps for the next maintainer, so we should do that anyway :). Thanks @bart-van-ingen-schenau.
    – Gilberto Matos
    Mar 21 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.