Please consider Apache Software License, Version 2.0

[MufriA]

I know its too much to ask, however since you done all the code changes to make library compatible with Android except that its licence LGPL.

As explained in https://source.android.com/source/licenses.html its clear we cannot link stoken dynamically in Android.

Could you please consider changing the licence to Apache Software License, Version 2.0

[cernekee]

As explained in https://source.android.com/source/licenses.html its clear we cannot link stoken dynamically in Android.

At that link Google lists the reasons why they avoid LGPL in AOSP and in factory images. Is that the use case that you're concerned about, or did you just want to add libstoken to your app?

For an example of the latter, see https://github.com/cernekee/EasyToken

[MufriA]

@cernekee I just want to use libstoken in my app like how you used in EasyToken

correct me if I'm wrong, lgpl2 mandates to link the library dynamically.

https://www.tldrlegalxcom/l/lgpl2

Since you own both stoken and easytoken you can link as you wish, how about others? including the lib in app will violate the license right?

[cernekee]

For the C portion, libstoken.so would normally live under libs/ARCH/ and it would be dynamically loaded through the JNI mechanisms. Somebody would be able to unpack the apk, replace the library with a new version, and rebuild the apk - all without touching classes.dex or other parts of the app. This satisfies the LGPL.

For the Java wrapper, I could see a potential issue building the LGPL jar file into an app with an incompatible license. It might make sense to relicense the Java wrapper files as BSD-3-clause to support this use case. Using the BSD license instead of Apache here keeps them compatible with GPLv2 code.

How does that sound?

[MufriA]

Sounds awesome, BSD seems good, thanks for considering the request.

[MufriA]

Thanks