On 26/01/16 20:23, thatsanicehatyouh...@me.com wrote:
Hi,
I’m working on a program that I will be submitting to the Mac App Store that
uses LGPL code. I have recently learned that the license requires the
capability for the end user to create their own version of the LGPL library to
link against the application (I have been compiling the source directly into
the library). This means at run time I need to either load the library from
what I provide in the application bundle (default, obviously), or, if present,
load one that the user provides. I can imagine wrapping the library in a
framework could be an answer. It would be up to the user to build a framework
in the correct format (I could easily make an Xcode project to do so available
on GitHub).
Is this possible/allowed for an App Store application?
I'm not sure it's allowed, you would have to check the App Store EULA
and license, and your Apple Developer Program agreement, etc.
If so, is this the best approach? How would I load the library at runtime given
that I normally link against it when I build the application?
You cannot use dynamically loaded libraries on iOS.
Also, I think you won't be able to load a library yourself (as data) and
jump into it (as code), since I'd expect the iOS kernel and MMU to
restrict execution of data in iOS.
No, the only way to use a library in iOS, is to link it statically.
However, you can still respect the terms of the LGPL with statically
linked programs. All you have to do, is to provide the binaries of your
program as object files (or a library of them), with a Makefile or a
script to link your object files with the LGPL static libraries into a
new final executable.
Now, given the complexity of the the Xcode/iOS build process, it may not
be simple to collect the required object files, and to write a Makefile
or script to do this final link, but you copy-and-paste the output of
the compilation/link in Xcode, and extract the commands used, that would
be a good start to write your linking script. (You would also have to
provide the resource bundles, if your application has such).
Now of course, the question is what will a user (even a programmer!) do
with a set of object files and a linking script? I mean, he could
always link a new executable with his modified LGPL libraries, but he
would still have to be a registered developer to be able to sign the
application and install it on his iDevice. He couldn't push it on the
AppStore, since it would be basically a duplicate of your application in
the AppStore, and Apple forbids duplicates (theorically; there are still
tons of implementations of the same game or utility in general). As an
registered Apple Developer, he could use Xcode to install his copy of
the program only on a limited number of test iDevices, and he could
certainly not _distribute_ it in any term.
This, AFAIK. A closer reading of Apple licenses and legal agreements
would have to be performed to refine this question.
--
__Pascal J. Bourguignon__
http://www.informatimago.com/
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
