I've been wondering about how to interpret or apply the LGPL in the context of PlayBook apps, especially after hearing that Qt will play a central role in the BlackBerry 10 environment (including supporting Cascades).
The common interpretation of LGPL is basically that if you modify the library, you have to provide source, whereas merely linking the library to your own program has no impact on your rights to distribute the program under any license terms you may choose.
In fact the LGPL terms, and intent, are clearly such that the linking has to be done in such a way that the end user may, if they wish, substitute a modified version of the library for use with your program. This would come from the Combined Works section in Version 3, 29 June 2007 (currently at http://www.gnu.org/licenses/lgpl.html), where it states as one option "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."
My concern here is that, since users will not have the ability to actually substitute a modified version of the library on the system, and possibly may not have access to our app's code, the basic architecture of a tablet like the PlayBook may prevent us all from actually complying with the terms of the LGPL.
The only way I could see this working, at the moment, is if it was accepted that users could extract an app's code from an unencrypted backup archive, add their own version of the LGPL library in question (e.g. libqtcore.so or whatever it may be), modify or regenerate the MANIFEST.MF as required, repackage and sign, side-load or restore the modified app package back into the system, and be able to carry on using it. One problem with that is, I believe, an effort in RIM to implement some improved form of piracy-preventing in the backup mechanism, possibly through some sort of encryption. Any mechanism of that sort other than use of the dynamic/pooled license keys that App World can support would block this approach for compliance with the LGPL.
Has anyone considered this question? Is there any chance we're going to have to deal with legal issues from the Free Software Foundation in future, once this complication becomes more widely visible? Or is it believed (or confirmed) that this really isn't an issue and that the terms of the LGPL will be considered as met merely through us continuing to link with Qt (or other LGPL-licensed library) through the usual shared-library mechanism?
