Using LGPL library in Paid Android App

Question

Can I use a LGPL library in my paid android application? I am not going to modify the LGPL lib, I just want to use it. Is it legal?

Thanks @willytate @MisterSquonk; I found more info on other forums that only partially answers the question. Seems LGPL only reluctantly allows dynamic binding in commercial apps, meaning it just wont work on Android because Android translates all classes and jars to a single bytecode "dex" file, which could be a breach of LGPL. Unless some legal expert shed some light, its better to be careful. More links: http://www.andengine.org/blog/2010/11/andengine-and-the-lgpl-clarification/ http://groups.google.com/group/android-developers/browse_thread/thread/587d0323cd1b18fe/aa190c051bedfa0f — Kamran, Feb 07 '11 at 19:52
I think the AndEngine guy doesn't understand the LGPL, and his blog post only confirms that. — Enno, Mar 30 '11 at 16:41
Yes, I agree, I also checked with the authors of the lgpl-lib, they didn't have any issue with using their lib in paid android apps. I also found some other paid apps using LGPL and ASL libs. — Kamran, Apr 18 '11 at 13:29
it was not clear from your question whether it was about a Java or native library. For the latter, the answer is rather simple. I believe that LGPL "user" can be restricted to a junkie with a rooted device, therefore they can rebuild the (dynamic) library and replace it in the /data/data//lib directory (and hope that the new version does not introduce breaking changes ;). For Java, Android architecture provides "dynamic" linking (through AIDL), but I don't fully understand the compliant ways of distribution of such libraries. — Alex Cohn, May 16 '11 at 11:12
@Alex... It is java lib, a jar file licensed under LGPL, my android app uses it and has a compile time dependency on it; so I include it as a jar file in my project. Now when I compile my app, I don't see the jar inside the resulting APK, so I assume the jar file gets merged in the single DEX file for the whole app. This DEX file is all dalvik byte code, so it is not dynamic linking. Although the author of the lgpl-lib doesn't have any issues with it; but I just wanted to know if LGPL itself allows something like that. — Kamran, May 18 '11 at 10:43
I'm voting to close this question as off-topic because it is about licensing or legal issues, not programming or software development. [See here](http://meta.stackoverflow.com/questions/274963/questions-about-licensing/274964#274964) for details, and the [help] for more. — JasonMArcher, Jun 03 '15 at 03:50
Check this answer out: http://programmers.stackexchange.com/a/205926 In short, you can compile the library as `.so` and pack it in the `.apk`. — user, Mar 21 '16 at 08:25
I believe questions related to programming, even if not strictly about programming, should NOT be closed. — Yar, Dec 01 '16 at 11:22

greywolf82 · Answer 1 · 2015-01-08T08:39:57.233

Using LGPL in an android free or paid app is legal, but to be compliant with the LGPL you have to:

Give the user indication of the library used and where to find the original code;
Configure proguard to not obfuscate the code covered by LGPL;
Avoid any check in your app about signature compliance;
Give to the user indication of how replace the library.

For point 4 you can indicate to use dex2jar, replace the LGPL code and re-sign the APK. It needs a lot of work for the user but it is possible to do it and allow the final user to recombine or relink the code as LGPL says. In addition, if your app uses any google services, the user need to create an account to generate the own api key and so on.

In my opinion, this should be the accepted answer – Jose_GD Feb 23 '16 at 20:44 — Jose_GD, Feb 23 '16 at 20:44

score 13 · Accepted Answer · answered Feb 01 '12 at 14:10

If you're making a paid Android app you'll probably have problems with a specific issue of LGPL: substitutability. Generally, it states that when you distribute a combined work you have to provide a user with possibility to substitute the library with a different version (e.g. newer). Very doubtful in the case of DEX file, as mentioned in previous comments.

An alternative to a single DEX file is to make from a dependent library a separate application, released on LGPL. In such an application you create a service to which you connect from your paid application. Then, to substitute the LGPL library with newer version only recompilation and reinstalling the library's APK is required.

The hassle is, of course, that now you have more than one APK to install.

score 9 · Answer 3 · edited May 23 '17 at 12:34

I am not a lawyer, but from my understanding of the GNU Lesser General Public License 3.0, section 4 explicity excludes static linking as the requirement states:

You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:

[...]

d) Do one of the following:

0) 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.

1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

(Emphasis mine.)

Section 4d.0 is not possible by the nature of Android APKs: the APK is compiled to Dex and signed as a whole, containing referenced libraries, and hence swapping out libraries cannot be done without the original source code, the keystore and keystore password.

Section 4d.1 may be possible by deploying two APKs:

One APK containing the LGPL library and in turn open source and licensed under LGPL
Another proprietary APK referencing the LGPL application.

Deploying such an application, however, is not possible directly through Google Play without specifically adding the requirement that the user proceed to download the LGPL dependency, which would need to be deployed as a separate application on Google Play. This would be very tedious for the end user, and realistically isn't an option for a typical consumer application.

As per the discussion with Prof. Falken in William Tate's answer, the terms of the LGPL may be more applicable to C libraries included through native code, as they reside inside the APK as a separate library. Although the APK cannot be signed, it is possible to repack the APK with the object file replaced. From my perspective, that technically fits the requirements of the license.

+1 This is a far better and more in-depth answer than my original (read: lazy) attempt. — Will Tate, Nov 24 '13 at 21:38
The last point does bring up an interesting approach for Java libraries: if you provide the jar in the `res/raw` folder and dynamically load it, is may be possible to recombine the application to fulfill section 4d.0. — Paul Lammertsma, Nov 24 '13 at 21:50

score 7 · Answer 4 · answered Apr 10 '13 at 16:30

7

The droidText library (used for exporting to PDF format on Android and released under LGPL) has a detailed explanation of how to use their library and still comply with the LGPL:

http://code.google.com/p/droidtext/wiki/LGPLCompliance

I found it very helpful. Basically you use a utililty (dex2jar) to take the jar of the library OUT of the dex file- thus allowing and end user to update with a later version of the droidText library if they want to.

answered Apr 10 '13 at 16:30

frisbee

71
1
1

9

Link is broken ;( – OneWorld Jan 17 '14 at 19:35
My interpretation of the license itself is that no reverse engineering should be needed for a user to recombine an application. While the developers of droidtext seem like they're cool with including their library it into proprietary software, my primary concern is that other owners may have a stricter interpretation of LGPL. – Paul Lammertsma Feb 26 '16 at 12:49

score 3 · Answer 5 · edited Apr 25 '13 at 16:54

3

This should outline your main concerns: http://answers.google.com/answers/threadview/id/439136.html

Most of it seems to be disclosing your use of the library and making sure you adhere to the rules of distribution according to the license.

edited Apr 25 '13 at 16:54

Prof. Falken

24,226
19
100
173

answered Feb 06 '11 at 22:12

Will Tate

33,439
9
77
71

1

Yes I did read that thread, I have no issues disclosing the use of the lgpl lib; my only concern is that the android SDK produces a single "dex" file against all the java classes and jar libraries used. This resultant dex is all object/byte code, which is then packaged in the apk. It is not really dynamic linking... Can this be a breach of some lgpl article. – Kamran Feb 06 '11 at 22:26
3

I think it might be a breach. LGPL would appear to require the library portion of your code to be editable. – Will Tate Feb 06 '11 at 22:35
It is not a breach to statically (or "non-dynamically") link if you include the source of the LGPL library. – Prof. Falken Apr 25 '13 at 16:55
@Prof.Falken Can you elaborate on that a little? The license appears to explicitly *exclude* static linking [under section 4d](http://www.gnu.org/licenses/lgpl.html#section4). – Paul Lammertsma Nov 24 '13 at 16:16
@PaulLammertsma, hm, now that I read it again, one would have to distribute the object files which would allow the user to relink the static executable again with a new version of the library, as well as the LGPL library itself. So, basically, it's a pain. – Prof. Falken Nov 24 '13 at 17:56
@Prof.Falken The LGPL does seem to imply that it was written with C libraries in mind, but doesn't make any mention of object files. It's certainly true that swapping native libraries is possible on Android, so perhaps the license only holds for native libraries? – Paul Lammertsma Nov 24 '13 at 19:02
@PaulLammertsma, it seems to the license tries to be language neutral: "Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink". – Prof. Falken Nov 24 '13 at 19:14

score 3 · Answer 6 · answered Feb 07 '11 at 00:03

3

I've always thought LGPL was very much a 'grey area'. Although there are specifics on how LGPL code/libraries etc should be used, it doesn't necessarily reflect the exact requirements of the author(s).

Personally I would recommend contacting the author(s), explaining your concerns and asking if they are happy to allow you to use it.

answered Feb 07 '11 at 00:03

Squonk

48,735
19
103
135

I am accepting this as the right answer; I agree it is a grey area and the authors should be asked if they are happy with the intended use of their library. – Kamran Apr 18 '11 at 13:31
10

I don't think it's the right answer. After you license your stuff with LGPL, later on, not your personal opinion / actual mood / etc. counts but LGPL itself. When somebody is in doubt about applying an LGPL stuff in his/her stuff, he/she should consult a lawyer. – gyorgyabraham Dec 18 '13 at 10:54

Using LGPL library in Paid Android App

6 Answers6

Linked