I'm investigating the legal issues of using LGPL native libraries in a closed source Android software.

As for now, my research on the subject shows that using LGPL libraries in closed source software is doable, and that the requirements are not specially high.

On a regular application (for example a C closed source application), I would dynamically link the library, and distribute the binaries of the application along with the library with proper reference to it and instruction on how to replace this library with the version the user would like to. (I may be forgetting some stuff here but this is not the point of my question).

My question refers to Android software and JNI. Assuming I am building an Android software using JNI I do have :

My java source A JNI folder including :

  • Android.mk file for the compilation of the application
  • the library source code
  • .cpp/.h files linking the source code with JNI

To compile my application, two steps are required :

  • Compilation of the library using NDK to generate a *.so file
  • Compilation of the Android application using Ant. The java code includes a System.loadlibrary("nameOfTheLibrary")

The problem I am facing is that the source code of the library is first compiled to a *.so file. This can be considered as derivative work, am I right ?

How could I include the native LGPL libraries and distribute it in a proper way to avoid any legal problems ?

  • This question appears to be off-topic because it is about legal advice. Please consult a lawyer.
    – JJJ
    Jul 24, 2013 at 8:00
  • Althouh you may be right that there is indeed a legal part in this, my question is centered around the technical way to distribute a closed source android software linking native libraries using JNI. I doubt that a lawyer could answer me on that part.
    – Al_th
    Jul 24, 2013 at 8:04
  • 1
    @Juhana: IMAO should definitely be migrated back on stack overflow. The legal part is motivation, but correct answer is purely technical. How to set up Android build system so the libraries are dynamic.
    – Jan Hudec
    Jul 24, 2013 at 12:43

2 Answers 2


Your code is compiled to a .so. But that includes just your sources and any libraries linked statically, i.e. as .a. Libraries that were compiled separately to .so are separate.

So you must generate separate .so files from the LGPL parts and separate .so from your code, which will be linked to the other .sos (this is the dynamic link that stops LGPL from applying further). All of those .so files than have to be packed into the .apk (the build system should place them in the right directory automatically) and the user can replace them and repack the .apk (and have to sign it with their key, but since any valid key will do, that's fine)

The build system should be able to define any number of shared library modules (I don't remember the details, I am compiling android libraries with CMake, so look at the documentation). And remember that the makefiles describing how to build the LGPL libraries are considered source by LGPL too.

  • Unless it is the only way to replace a .so installed by application X, I don't believe there is the requirement that the user can repackage application X with modified libraries. To satisfy the LGPL, it is sufficient that there is a way to replace the libraries on an installed system. Jan 31, 2014 at 14:01
  • @BartvanIngenSchenau: On Android it is the only way that does not require rooting the device, yes. And it's simple; the .apk is good old .zip signed with normal jarsigner. So in practice the requirement boils down to that the proprietary code must not insist on being signed with the original key.
    – Jan Hudec
    Jan 31, 2014 at 14:24

While you have to rebuild the LGPL lib, that doesn't mean your app that links to it falls under the definition of derivative work - only that your work in rebuilding is.

So, as long as you release the code (contribute it back to the project, for example) that enables you to get it running on Android, you're going to be ok.

Your Answer

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