Are LGPL libraries allowed on the Mac App Store?

I've read conflicting opinions on this. Is code licensed under the LPGL allowed to be used on the MAS?

Replies

Yes, but you are responsible for all code in your app regardless of where it came from. If you feel comfortable accepting responsibility for that code, then go ahead. You do need to make absolutely sure, though, that the code in question is in fact LGPL and not GPL. If you use GPL code, your entire project must become GPL, which I don't think is approved for App Store release. (Just my opinion, though—I may be wrong about this 🙂)

Yeah, the library has been around for awhile and has a pretty good reputation out there in the wild. The only reason why I'm thinking of using it, is because my app currently relies on Quartz, and Apple introduced a bug in El Capitan that broke core functionality of my app.


I'd use this library instead of Quartz, to get back what I already had on Yosemite. I of course have no access to the source code of Apple frameworks. I dropped down to the Core Graphics api to try to workaround the problem, but quickly hit another roadblock. I filed a TSI but Apple said what I was looking for wasn't currently supported using the Core Graphics APIs. So I'm stuck waiting hoping they fix the bug in a OS X update.

Going down to raw C without any support from a framework is a pretty big undertaking. There aren't alot of libraries out there. I found some Python libraries under the MIT License but they aren't really good enough for production release. This library seems to be the most complete but is LGPL. I've heard some people say that both LGPL and GPL are not allowed on the App Stores. But I see no reason why LGPL wouldn't be allowed on the App Store, since you can use it in a closed source project.

Did you file a radar in addition to the TSI? Unless you make it known that there's an issue, it won't get fixed!

yeah I filed a radar, quite awhile ago 😢

You're best to consult a lawyer on this, rather than rely on forum opinions. 😉


That being said, I'd be wary of linking to LGPL libraries. The essential point about LGPL is (copied from LGPL v3):


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.


You will either need to allow anyone to relink your app with a modified version of the library or it has to be already present in the user's system. Neither of which seems particularly straightforward with App Store apps. In particular, I don't know if the code signing enforces the identity of all packaged dylibs; if it does, you wouldn't be able to substitute the library on a user's machine even if you gave them instructions on how to do it.


Cheers

Glen Low

Pixelglow Software

try.instaviz.com

The developers of this have a static library xcode project and claim you can use it in a commercial project. If I were to modify it and make it a framework wouldn't the user be able to do "Show Package Contents" and replace the .framework with a different version.


I remember a couple of years ago, when OS X server VPN broke, you could hack it by replacing racoon with an older version.


I really don't see why a developer would choose LGPL. I sort of can see why a dev may choose the GPL..if the developer is really philosphical about everything being "free" and what not..


If I can use this in a commercial closed source project, where I sell that project shouldn't matter. I'm not a lawyer, but I can't help but wonder, if someone did try to sue a developer for using LGPL code in a Mac App Store app, what exactly would the damages be when they don't expect to get money from the code in the first place.


Also this condition:


A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system


Sounds like hocus pocus. How can a developer know if the library will always be present on the user's system? The user could modify his system (though not typical) and remove a library. Also a OS update can change what libraries are available and what aren't.

The issue you're going to face is code signing. If Xcode (and the Apple servers) code signs both your executable and all packaged frameworks, then you cannot simply ask the user to replace a framework. Since code signing is meant to defeat malicious code, it stands to reason it will also check packaged frameworks.

You could probably use the instructions here to see what happens to packaged frameworks: www.objc.io/issues/17-security/inside-code-signing/

Thanks for the info. This library is licensed under LGPL version 2 not 3. I'll have to look to see if that suitable shared library bit is in version 2 of the license.