• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: LGPL code in the Mac App Store?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LGPL code in the Mac App Store?


  • Subject: Re: LGPL code in the Mac App Store?
  • From: Eric Wing <email@hidden>
  • Date: Fri, 29 Jan 2016 17:22:22 -0800

> I think a better technical approach would be to embed the library as a
> framework in your app, but arrange that if a version of the framework is in
> (say) /Library/Frameworks, that one is dynamically loaded instead of the
> built-in framework. You might also need to be able to provide the source
> code of the version you embedded, but it would be easy for users to
> substitute other (ABI-compatible) builds for yours.
>

Ignoring Mac App Store and Sandboxing for a moment, this could work
with Runtime Search Paths (LD_RUNPATH_SEARCH_PATHS). It allows
multiple search paths. I used to do this in the reverse direction to
have developer fallbacks if the framework wasn’t in the bundle (for
internal dev purposes…I was not signing). Under sandboxing, the real
/Library/Frameworks wouldn’t be accessible, but maybe the virtual/fake
one in the application sandbox would work and satisfy the problem if
codesigning didn’t get in the way.

I don’t know enough about the MAS signing/verification process. For
example, is it possible for me to add/permit my own private
certificate to my system keychain and then sign the framework? (Or
resign the entire app with my self-signed key that I told my system to
accept?)



> However, for designated frameworks, if there was a way — I dunno, an
> environment variable you could set — to adjust the load location of just
> those frameworks,


DYLD_FRAMEWORK_PATH and DYLD_LIBRARY_PATH do this, but I don’t know if
it has precedent over what’s compiled into your app. If it worked, the
users would probably need to launch via a shell, but whatever.

I suppose going the dlopen runtime route instead of compile time
linking could avoid these problems.

_______________________________________________

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


References: 
 >Re: LGPL code in the Mac App Store? (From: email@hidden)
 >Re: LGPL code in the Mac App Store? (From: Dru Satori <email@hidden>)
 >Re: LGPL code in the Mac App Store? (From: email@hidden)
 >Re: LGPL code in the Mac App Store? (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: catching statuses of lights
  • Next by Date: Re: catching statuses of lights
  • Previous by thread: Re: LGPL code in the Mac App Store?
  • Next by thread: Re: LGPL code in the Mac App Store?
  • Index(es):
    • Date
    • Thread