Open source and app stores: Where they mix, where they don't

GPLv2 is especially problematic for apps available via the Apple App Store and Windows Marketplace, but you have alternatives

App stores are all the rage these days, with companies vying to release their software ahead of competitors. Not surprisingly, open source components are being used to speed development of these applications. But companies need to ensure their open source usage fits within the requirements of both the app stores and open source component licenses -- or risk removal from these outlets (and not just Apple's).

Companies using open source aren't complying with licenses

OpenLogic recently released results from a scan and license compliance assessment of 635 leading mobile applications. Of these, 66 applications -- just over 10 percent -- were found to contain components with an Apache or GPL/LGPL license. Among these 66 titles, more than 70 percent failed to comply with requirements of the open source license.

HTML5 Deep Dive
[ Get the latest insights and news on open source trends with InfoWorld's Technology: Open Source newsletter . Subscribe today! | Learn how to develop for HTML5 in InfoWorld's HTML5 Deep Dive PDF special report. ]

OpenLogic's analysis suggests that companies using open source components in their app store offerings are doing so without fully understanding license implications. That's dangerous: Ignoring license requirements means that your application could be pulled from the app store, thereby harming your competitive position and frustrating your users.

GPLv2 and Apple App Store license incompatibility is the pressing concern

Another issue to consider is that the terms of service at the most popular app store -- the Apple App Store -- is incompatible with the GPLv2 license. Companies considering using GPLv2 components in their App Store-destined application should think twice, unless the incompatibility is resolved. Until the GPLv2 and App Store incompatibility is remedied, I encourage you to seek legal counsel before using GPLv2 code in your App Store-destined applications.

What's the issue? The GPLv2 license doesn't allow someone to impose further restrictions on the code than outlined in the original licensor agreement. The GPLv2 also doesn't allow restrictions on usage. On the other hand, the Apple App Store terms of service prohibits usage as defined in the list of rules: If an activity does not appear on the list, a user is not allowed to employ the App Store application in that way.

In effect, in the context of a GPLv2 license, an Apple App Store item that abides by Apple's terms of service is deemed to be restricting usage and imposing further limitation on usage rights than were envisioned by the original licensor of the open source code.

Far from being an abstract example, this situation is precisely why the popular VLC media player was removed from the App Store.

Although Apple does not explicitly prevent applications from using GPLv2 licenses (the de facto prohibition comes from the conflict with Apple's terms), Microsoft made waves when it was revealed that the Windows Marketplace did not allow apps to use copyleft licenses such as GPLv2. Considering the situation that companies face when developing for the Apple App Store, you can understand why Microsoft thought it easier to disallow the use of GPLv2 altogether.

Android and dual licensing present a glimmer of hope for GPLv2 in app stores

Unlike Apple and Microsoft, Google doesn't place limitations on the use of GPLv2-licensed components in the Android Market. However, companies are increasingly opting to build an application once with a set of core components and then tailor it for multiple device platforms. This strategy limits component license selection to a least-common-denominator approach across devices. Even if the Android Market allows GPLv2 components, if largely the same application is going to be available on the Apple App Store or Windows Marketplace, then GPLv2 components aren't the right choice.

With the vast amount of GPLv2 code available for use, the incompatibility between the App Store's (and Windows Marketplace's) terms of service on one hand and GPLv2 on the other is a problem in need of a fix. Stephen Walli, a Network World contributor and OuterCurve's technical director, proposed a solution that relies on dual licensing of GPLv2 components:

This suggests a way for developers that are strong believers in free software to also use the Apple App Store as a channel to get their software in front of a larger audience. The project could essentially create a dual licensing scheme using the GPL for its wider audience and a separate Apple App Store distribution license for the executable version and its derivatives that sits on the App Store and that further allows others to use and to publish the binary on the App Store.

The key challenge with this approach is for GPLv2-licensed open source projects to agree that creating a new App Store-friendly license is appropriate. Some developers who believe in the freedoms enabled through the GPLv2 will likely resist supporting a license that restricts user freedoms. Additionally, open source projects that rely on third-party open source components would require each third-party project to agree to a dual license -- or else find a replacement project -- before the parent could use a dual license.

Apply sound open source usage principles to App Store apps

The Apache 2.0 license doesn't have the same issue as GPLv2 when it comes to Apple's App Store terms of service, so it could become the license of choice of companies seeking to use open source.

Additionally, it's not a good plan to blame developers, contractors, or third-party service providers for improperly using open source software within your company's app store offering after the fact. Instead, ensure your company has guidelines and approval processes in place, just as you would for using open source in internal projects. Opt for a license scanning and governance product from vendors such as OpenLogic, Black Duck, or Protecode to validate that projects are adhering to your company's open source usage guidelines.

It's good practice for internal open source work and a must for apps you plan to distribute through an app store.

Follow me on Twitter at SavioRodrigues. I should state: "The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions."

This article, "Open source and app stores: Where they mix, where they don't," was originally published at Read more of Savio Rodrigues' Open Sources blog and follow the latest developments in open source at For the latest business technology news, follow on Twitter.

Copyright © 2011 IDG Communications, Inc.