On Android, the post Using Qt as shared system libraries in Android (https://www.qt.io/blog/using-qt-as-shared-system-libraries-in-android). It shows how to add the Qt libraries as system libraries on the Android device. System apps can access the system libraries and don't have to provide Qt over and over again. Normal apps can't access these libraries.
The app publisher must provide everything necessary to build, install and run the app:
- A way how to build modified Qt libraries with an Android or iOS SDK.
- The object file of the app executable without Qt libraries.
- A way how to link the executable object file with the static Qt libraries yielding a new app executable.
- A way how to install the new app on the phone. It's OK if the user must pay for, say, an iOS developer license to allow side-loading on an iPhone. Side-loading isn't a problem on Android.
All this steps must be well documented so that the user can reproduce them.
I think that your question is answered by the last step. Yes, side-loading apps and paying for it (e.g., 100 USD for the iOS developer program) is allowed by LGPLv3. Users create a new package for the app and side-load it on the device.
In the case of an iOS or Android app available through App Store or Google Play Store, it looks pretty difficult to provide a mean to replace the Qt dependencies since app publishers can only submit a single package.
So to enable one to link a iOS/Android app against its Qt library builds, the app publishers should provide a mean to generate a specific APK/IPA using these specific Qt library builds. This is the only solution I see.
Do you think such solution would be compliant with LGPL or does all iOS/Android apps fall into Qt commercial category by the way apps distribution is designed?
Hi David,
On Android, the post Using Qt as shared system libraries in Android (https://www.qt.io/blog/using-qt-as-shared-system-libraries-in-android). It shows how to add the Qt libraries as system libraries on the Android device. System apps can access the system libraries and don't have to provide Qt over and over again. Normal apps can't access these libraries.
Cheers,
Burkhard
Hi David,
The app publisher must provide everything necessary to build, install and run the app:
- A way how to build modified Qt libraries with an Android or iOS SDK.
- The object file of the app executable without Qt libraries.
- A way how to link the executable object file with the static Qt libraries yielding a new app executable.
- A way how to install the new app on the phone. It's OK if the user must pay for, say, an iOS developer license to allow side-loading on an iPhone. Side-loading isn't a problem on Android.
All this steps must be well documented so that the user can reproduce them.
I think that your question is answered by the last step. Yes, side-loading apps and paying for it (e.g., 100 USD for the iOS developer program) is allowed by LGPLv3. Users create a new package for the app and side-load it on the device.
Cheers,
Burkhard
Hi Burkhard,
In the case of an iOS or Android app available through App Store or Google Play Store, it looks pretty difficult to provide a mean to replace the Qt dependencies since app publishers can only submit a single package.
So to enable one to link a iOS/Android app against its Qt library builds, the app publishers should provide a mean to generate a specific APK/IPA using these specific Qt library builds. This is the only solution I see.
Do you think such solution would be compliant with LGPL or does all iOS/Android apps fall into Qt commercial category by the way apps distribution is designed?
Thank you,
David