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: Thu, 28 Jan 2016 23:06:47 -0800
IIRC, for Mac App Store apps, your app has to perform copy-protection checking itself (i.e, receipt checking); Apple specifically didn’t want to do that themselves so that when the inevitable crack appears in the wild, it doesn’t take out the whole app store - just the apps that the particular crack applies to.
iOS, I believe, is different.
(it’s been a while since I watched the relevant WWDC videos, though; and I haven’t had to implement such receipt checking myself yet, so take that with appropriate quantities of NaCl).
******************************************************
I am not a lawyer, nor do I play one on TV, but… I **think** that this section (taken from v3.0 of the LGPL):
> 4. Combined Works.
> You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:
>
> • a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.
> • b) Accompany the Combined Work with a copy of the GNU GPL and this license document.
> • c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document.
> • d) Do one of the following:
> • 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
> • 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
>
...means that the user must be able to modify and re-compile the library, and re-link the executable in toto, and (assuming that no errors were made during the modification phase) have the combined product run. Any code-signing or DRM system that prevented this, would to my eye, seem to violate the LGPL.
******************************************************
The current version of the Apple Developer Program Agreement states in section 3.3.2 that MAS apps can run plugins, so I would presume that a sandboxed, code-signed MAS app can, in fact, load them. I haven’t actually tried it though (my apps that have a plug-in system, although code-signed, aren’t sandboxed MAS apps).
Also, now that I think about it… FWIW, wasn’t there a linker flag that told the system where to look for .dylibs?
_______________________________________________
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