I think that this is a slightly uncharitable view of OSS devs, but not terribly inaccurate.
> On Jan 29, 2016, at 1:30 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Jan 29, 2016, at 09:27 , thatsanicehatyouh...@me.com wrote: >> >> One thing I forget to add; probably the *very best way* to address this >> issue is to contact the library author and say, “Hey, I want to use your >> LGPL code in my Mac app and put it on the App Store; is that ok? Do you mind >> if people can’t dynamically link their own copy, because really, no one will >> want to?” > > This is rational, but unfortunately doing this makes the library *free* > software, not *open source* software. > > The open source “hook” — what makes it attractive for a public spirited > programmer to make it available to everyone — is that it permits others to > play with the code downstream. That means (say) faster versions of the > algorithms, or the extraction of intermediate results for interesting new > uses, etc. Humanity is benefitted. <ahem> > > This doesn’t work with the above suggestion. In fact, the library author is > likely to say, “Hey, I wrote this software, and you’ve made it an essential > component of your app, and you’re *selling* the app and making yourself rich > with the money??? Gimme some.” > > 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. > > The problem is that I don’t think there’s a mechanism for doing this. The > path to the embedded framework is baked into the app, I believe, and you > can’t change it without invalidating the code signature of the app. Further > it would be a horrible security hole if you could simply override any > embedded framework in any with an external hacked one. > > 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, the result would be approximately in the spirit of the > LGPL. > > But I’m certainly not holding my breath on this. > > _______________________________________________ > > 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/dru%40druware.com > > This email sent to d...@druware.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
