Now you are getting into the nitty gritty of LGPL wording and implementation, at that point, it becomes more about working with the copyright holder to ensure you are complying with the intended spirit of the license, or engaging a lawyer to get him to sign off on a willingness to defend the implementation in courtroom.
I know a lot of people denigrate the LGPL without enough information, but to me, this is the real issue with the LGPL as it stands. There remains too much grey area. That said, I’m with Jens. an embedded .dylib meets the letter of the LGPL. IIRC, the question of static linking against a .a has also been upheld, so long as application provides value above the library, and the app could function (albeit with lesser functionality) if built without the library. On Jan 26, 2016, at 4:33 PM, Jens Alfke <j...@mooseyard.com<mailto:j...@mooseyard.com>> wrote: y the terms of the license. It’s not like a lot of actual users are going to be replacing the library, so there’s no point going to more work to make _______________________________________________ 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
