Mac App Store, not iOS. I would consider a: packaging a version of the library in your resources; and loading that if there is not one in the app’s Application Support folder; and b: providing the library on github. If the user wishes to modify the library for whatever reason, they download it; modify it; and stick it in the app’s container’s Application Support folder in the appropriate location; and the app loads that version instead of the version packaged from the app store.
Disclaimer: I haven’t actually tried it; so YMMV... > On Jan 26, 2016, at 1:06 PM, Pascal J. Bourguignon <p...@informatimago.com> > wrote: > > > > 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/bdurbrow%40rattlesnakehillsoftworks.com > > This email sent to bdurb...@rattlesnakehillsoftworks.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
