Let's consider a proprietary Android app which is using an LGPL library.

LGPL requires that the user could be able to replace the library with a modified version. For languages like C, LGPL suggests either using a dynamic library, or making object files available for static relinking.

In the case of an Android APK, you cannot just drop in a .jar with a modified LGPL'd library. OTOH sufficient open source tools (e.g. ApkTool) exist to deconstruct the APK into class files, replace the file(s) related to the LGPL'd libraries, and make an installable modified APK back from these (e.g. using the Android development tools which are also open-source).

Should the presence of such well-documented, widely known tools be considered sufficient in order to not make the raw class files of the app available, and be still compliant with LGPL?

I hope extensive prior cases exist for this particular configuration.


1 Answer 1


This is probably allowed if you include a tool to deconstruct the APK into class files in your distribution. The LGPLv3 says in 4(d)(0) that you must:

Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

So that's:

  • The Minimal Corresponding Source of the LGPL-covered library, and
  • The Corresponding Application Code of the non-LGPL'd components

Minimal Corresponding Source is simply the source code of the library and may exclude source of the Application that is linked to the library:

The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.

The Corresponding Application Code is the object object (or, optionally, source code) of the Application, plus utility programs (emphasis mine):

The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.

So we know that the Corresponding Application Code must:

  • be in a form suitable for... the user to recombine or relink the Application with the library, and
  • includ[e] any data and utility programs needed for reproducing the Combined Work from the Application

Based on your assertion that the APK can be deconstructed into classes if the user has a particular tool to perform that transformation. The remaining question is: does such a tool as ApkTool fall within the category of "utility programs needed for reproducing the Combined Work from the Application"? If so, you must include such a tool as part of the Corresponding Application Code.

I am included to say such a tool would be part of the Corresponding Application Code, since without that tool, there is insufficient tooling to reproduce the Combined Work with a modified library. You might point out that a compiler or linker would fall under this definition -- and those, too, are surely needed to reproduce the Combined Work -- but it seems that those tools would be required in any case (even with the class files directly) whereas ApkTool is required only when you opt to bundle the files inside of a build APK only.

Since your distribution requires at least the library source code, I would say it's not much more trouble to include either the raw class files or ApkTool alongside that library source.

  • 1
    Thanks! I suppose it would be sufficient to just make the APK and ApkTool available on the web, with a link in the application's "About" box? Including that inside the application itself, which is a mobile app, is probably not very useful, the operation can't be reasonably done on a mobile phone anyway. Is this correct?
    – 9000
    Mar 10, 2020 at 17:59
  • It may be worth pointing out that while the license exempts “general-purpose tools or generally available free programs which are used unmodified in performing those activities” from the Corresponding Source definition, it explicitly includes build tools in the Corresponding Application Code definition. This may be a drafting oversight, but as written I agree with your interpretations that tools for relinking must be provided directly.
    – amon
    Mar 10, 2020 at 21:40
  • 2
    @9000 the normal way to comply with (L)GPLv3 is offering a download of the Corresponding Source etc from some network server per section 6(d). This could be a GitHub repository, or a ZIP file on your website. But you need to provide clear directions to the source next to the object code, i.e. put a link in the description on the Play Store page or wherever you offer the app.
    – amon
    Mar 10, 2020 at 21:43

Your Answer

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

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