Re: LGPL code in the Mac App Store?
Re: LGPL code in the Mac App Store?
- Subject: Re: LGPL code in the Mac App Store?
- From: Britt Durbrow <email@hidden>
- Date: Tue, 26 Jan 2016 13:17:29 -0800
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 <email@hidden> wrote:
>
>
>
> On 26/01/16 20:23, email@hidden 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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden