Tuesday, December 18, 2012

Your LGPL license is completely destroying iOS adoption

tl;dr If you have LGPL licensed code, please be clear if you want it to be used alongside proprietary libraries in iOS.

I hesitated about writing this because it will surely put some people up in arms (many of them good friends). So please let me clarify before throwing grenades.

This is not FUD. For the uninitiated in Open Source licensing discussions, “FUD” usually refers to when somebody (usually with a hidden agenda to support a particular proprietary technology) starts throwing rocks at Open Source in general. The idea is that this person will create enough confusion, that the proprietary option will be chosen instead.

I don’t have any hidden agenda.

I actually admire Richard Stallman (the GNU father) a lot. It is impossible to argue that without his full-blown activism, sacrifice, and energy dedicated to the Open Source movement, we would not be where we are today. We have Open Source libraries for practically anything. Yes, RMS can do extremely odd things while discussing complex issues, but nobody can take away that he is really the crazy genius that changed the world for the better. Truth is, I think we need people like RMS to create a sort of equilibrium.

In the GIS space, we have several key projects that are LGPL'd. The main one that comes to mind is GEOS a port of the wonderful JTS library - and this is where the iOS problem begins (JTS is LGPL and thus GEOS has to be LGPL because it is derivative work).

GEOS is really at the heart most Open Source GIS projects; it provides the core geometry object model defined by a standards organization and it also has an amazing list of algorithms/functionality. Very popular key GIS projects like PostGIS, QGIS, GeoDjango, Spatialite (sqlite with spatial extensions) and others rely on GEOS for all the geometry needs.

Without GEOS, a lot of this applications become extremely crippled. Thus, why you will (sadly) not see strong adoption of spatialite on iOS.

OK, good. So why is this a problem for iOS devices?

Without getting into all the details of the obligations/freedoms/restrictions/whatever-you-want-to-call-it that come with all the different versions of LGPL, the LGPL license requires you to release all the source code of any library you link statically to. Let me emphasize the word static linking here.

So fine you say, use a shared library instead.

I can’t. iOS does not allow shared libraries!

Why?

They are afraid your app will download a new version of the shared library at runtime and change the behavior and thus circumvent the whole Apple App Store Review process.

Beefing up my anti-DDoS system. Why? Because this is the part where both camps start fighting like their life depends on it.

One side will say that Apple’s App Store is Censorship and that the LGPL clause is actually protecting your freedom. The discussion turns into a philosophical and ethical one. I can actually see how those argument are very valid.

The other side will say that the App Review process makes it more difficult for rogue code (notice difficult - not impossible). Having a review process reduces the possibility that your code will crash on devices after the first install because of something you did not test. It also reduces “duplication or redundant” apps - with Apple being the sole Ruler in choosing what goes in and out. Big brother I guess. But I also see how the App Store supporter’s point is a valid point.

Note that this problem does not exist in Android because it allows shared libraries to be compiled. Nevertheless, my customers use iOS a lot which means I cannot just “switch” to Android and “ignore iOS”. I need to use some proprietary libraries like Flurry and ESRI’s iOS SDK and many others for reasons outside the scope of this post.

Sigh.

Some people will argue that it is possible to do static linking of LGPL’d code and still be able to abide by the legal terms by providing the necessary binaries to be re-linked. This has no legal precedent and is still a very fuzzy argument. I would rather not bet my company on something so shaky as this.

So of course, some people may think: “Well then, you want to use other people’s hard work to profit in your [insert best insulting word here] startup. Sorry buddy, use something else! This was licensed as philosophical/political statement.”

And that is where they are right… and where they are also wrong.

OK, I should have added sometimes. For certain OS projects, like GCC, this is very true. Nevertheless, from personal experience, I’ve found many times when I am talking to leads/creators of some OS projects, that they are completely unaware that the default LGPL creates this complications in iOS.

The solution?

Some authors choose to add a static linking exception, others choose to re-license completely (think cocos2d that started as LGPL and switched to MIT). I am aware that for some projects with tons of contributors (think ffmpeg) it is impossible.

But if you have an awesome new project that could be extremely useful on iOS - and you have no philosophical or ethical issues with it - please please please please add a clarification to your licensing that covers this use-case. Even the Free Software Foundation doesn’t want you to use LGPL. So, please, pick sides, but don’t leave it in limbo state. If you don’t clarify, you are just completely destroying iOS adoption.

Hey, if you want me to release the changes / updates I make to your LGPL library, I have no problem with that whatsoever. I do it all the time.

What I refuse to do entirely is to completely ignore the licensing obligations altogether and just start using the library. Sadly, there are examples of Spatialite-with-GEOS/ffmpeg/put-your-favorite-lgpl-library-here code in the Apple App Store with developers who do not care one bit that they are violating those terms.

**Update (1/8/13): ** Corrected link to the current JTS site.

Notes

  1. rburhum posted this