LGPL Conditions

If you’re developing an iPhone application that you intend to submit to Apple’s App Store and you want to make use of a third-party’s software library that happens to be licensed under the GNU Lesser General Public License (LGPL), you have a couple of choices according to the license requirements:

  • You can open-source your app.  Specifically, you provide to your users the source code of your entire application under the LGPL or GPL.  That means for example all the .h and .m files.
  • You can keep your app closed-source, but you provide to your users all the object code of your  application necessary to re-link your application.  That means for example all the .o and .a files.  Most people forget that this option is in fact available to iPhone app developers.

Of course, if you modify the library itself, you have to provide these code changes in source form either way.

Dynamic/Shared Library

The above LGPL conditions can be thought to apply to the case when the LGPL library is statically linked.

But outside of the world of Apple’s App Store, the LGPL would normally give you another way to use LGPL code without releasing the source code or object code for your application: compiling your application with a run-time shared library (hence, allowing users to run your application with an updated library if they choose to).  The problem for us is that the Apple iPhone developer agreement doesn’t allow the bundling of shared libraries.

If you don’t care about the App Store and want to release/sell your application through Ad Hoc Distribution or to jailbroken devices (e.g. via Cydia), you can actually link apps with a run-time shared library and thus satisfy the LGPL without providing source code or object code.

Static Library Exception

Some library developers are aware of these iPhone and LGPL incompatibilities and provide a “static library exception,” loosening LGPL requirements for the iPhone platform.  For example, the cocos2d author intended to offer such an exception: even though he neglected to distinguish between the source code and object code requirements of the LGPL, it’s fairly clear he intended to relieve the app developer from having to provide source or object code even if they linked in the LGPL library statically.

It’s a good idea for you to consider contacting the author of the LGPL library you’re interested in to offer a similar exception for the iPhone.  That way you don’t have to worry about having to provide object code for your app.

Spirit of the LGPL

Whether you decide to release the object code for your app or take advantage of a “static library exception,” the spirit of the LGPL is violated by the iPhone restrictions: it becomes very difficult for your app user to customize your app with a modified or updated version of LGPL library.

Let’s say you do release all the object code and all the utilities that your app requires to build a new app based on an improved LGPL library.  How can your users install the new binary?  They are faced with the following unhappy options:

  • Jailbreak their iPhone to install any binary that they want
  • Join the iPhone Developer Program for $99 a year to be able to legally distribute “Ad Hoc” the new app to up to 100 devices.

In other words, you may end up spending a lot of time distributing object code to satisfy the LGPL and protect the source code of your app, but the object code is very unlikely to get used anyway.

In fact, even if Apple allowed apps to link with dynamic shared libraries, how could users even substitute the libraries without jailbreaking their iPhone?

No wonder the Free Software Foundation hates the iPhone.


This post is tagged , , , , , , ,

  • benclayton

    This is the best write-up of this thorny issue I've yet seen on the interweb, so thanks!
    I didn't realize that the option of distributing the .a and .o files was available either to iPhone devs. Does this mean though that anyone who did download your object files could link parts of your app (say, a particularly cool module you'd written) into their own? Seems quite risky. Also, wouldn't you need to distribute all of the resource files too? (graphics, audio etc) – eek!
    It seems likely that problems of this kind will simply have the effect of making LGPL licensing of iPhone-specific components less prevalent. Of course there's still mountains of platform-independent LGPL code out there that's presumably now best avoided.. :-(

  • huyzing

    As Pierre said on Nabble

    Or you could do like id
    Software did with Quake3 (and possibly their other games), only really
    protect the resource file and distribute the binaries willy-nilly.

    I guess it all depends on the level of risk you want to accept.

  • http://www.ytaccess.com/ Thomas Shin

    Hi, I'm trying to contact the author of this blog for a possible software dev commission and support on a previous project. However, I can't find any of your contact information, email address, etc. Please contact me at your earliest possible convenience.

  • Peter Crockford

    Regarding the “unhappy options” of deploying an altered binary, Section 1 of the LGPL 2.1 permits the developer to charge a fee for the physical act of copying the library. This provides a mechanism for the developer to reassign that fee towards the $99 Apple Dev subscription to allow them to do this for all their devices. How many people own more than 100 devices. They are redistributing a commercial application, so the developer’s own license terms come into play. A person cannot release their modified version into the wild and then complain that the 101st person couldn’t load the app. Only the end user who bought the original app has the option to modify and re-install.
    Also, since jailbreaking is legal and free, that also voids any concerns over LGPL and the Apop Store terms.
    There is no requirement in the LGPL that the end user has to have a “happy” choice, whatever that means. They just have to have a choice, and they have 2 perfectly good ones.

  • Sylvain Poitras

    Thanks, that was very helpful.

About MultiNC

Think up & Code up