Clarification on Qt / ios license
-
Getting the point:
- Qt is LGPL (or commercial)
- ios on device, afaik don't admit dylibs but only static libraries if they don't belong to apple kits
so if my application has closed source, the 3 solutions are:
to avoid Qt on ios and keep closed my source code
to use Qt but follow LGPL license
to buy Qt commercial license and keep my source closed using Qt
is there a solution in which I use Qt LGPL license and keep my source closed on ios device ?
thanks -
Hi,
This doesn't help older versions of iOS, but iOS 8 will support "dynamic frameworks":https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html so you can use LGPL there.
Note that the compatibility between closed source app + LGPL library + static linking is still unclear, because it has never been tested in a court of law. It might be ok; you'll need to consult a lawyer to know for sure.
-
thank you!
we consulted one year ago (as company) and he told that if you compile statically a third party library with LGPL, you are forced to disclose your code that links statically that library (part of it is inside the executable). But as you told, if until nowadays there is no verdict to clarify everything, it's difficult to trace a distinct line between what is allowed or not (I don't figure out how many quibbles a good lawyer can use) -
"You can keep your app closed-source, but you provide to your users all the object code of your application necessary to re-link your application. That means for example all the .o and .a files. Most people forget that this option is in fact available to iPhone app developers."
This is the quote from the article that gives a good explanation of how to deal with the LGPL code linked statically specifically for iPhone applications:
http://multinc.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/
