How to make app stores open source-friendly

These days, there’s an app store on every Internet corner. Increasingly, they’re being used as instruments of control by would-be monopolists seeking rents from their aftermarkets in the same way hardware vendors attempt this for connectors and supplies. Yet this abuse is built on a legacy of freedom. The pioneers were open source software communities; done right, app stores could once again become both convenient and open.

The heart of the idea that has become the app store was actually a solution to a different problem. The idea of having an install program that can resolve dependencies stretches back a long way — indeed, the SysV format provided in AT&T Unix has long been used to deal with that problem and led to many derivatives, notably the dpkg system in Debian. But an open source system can have many dependencies that are outside the control of a single entity, and resolving them automatically is probably one of the most important innovations to have arisen in software.

[ Also on InfoWorld: Who controls Vert.x: Red Hat, VMware, or neither? | Track the latest trends in open source with InfoWorld’s Technology: Open Source newsletter. ]

Systems like the Perl language’s CPAN (introduced in 1995), Red Hat’s RPM (introduced in 1997), and Debian’s apt-get (introduced in 1998) were responses to that need and became crucial to the success of the systems they enabled. None of them seems to have ever involved an authorization step, however; the networked repositories containing the code itself were as open as the software they distributed.

When mobile phones started to gain the ability to run apps, many companies realized that installing them was going to be an issue. The solution was package management, but presented to the end-user as a shopping experience. Generally, these app stores were a failure, lacking the critical mass to attract developers because they were too fragmented across handset brands and carriers and because the apps involved were not sufficiently compelling — until Apple embraced the concept.

Apple jumps in Apple’s App Store for mobile devices took the idea of shopping-themed package management and made it succeed by creating a compelling need for apps and by aggregating the markets of all their resellers. Neither alone would probably have been sufficient, but together, they were able to create the necessary critical mass. Other vendors have tried to follow suit; Google and Amazon have both been able to repeat the same trick successfully, using Android as a base. The obvious success of mobile app stores has led to their spread to other computing formats, with app stores appearing on Mac, Windows, and Linux desktops.

But in the process of bolting on the storefront, each has lost an important aspect of the original package management experience. By using the installation of software as a control point, the ability to have many individuals maintain quality control has been lost, and by linking that control point to monetization, the collaborative dimension of software creation has been diminished. Specifically, open source software is sometimes called out in developer agreements and in some cases discouraged or even forbidden. The incompatibility of Apple’s terms with copyleft open source licenses led to action being taken against Apple over the popular VLC video player when it appeared in the Apple iOS store.

Despite this, open source software is endemic in app stores. OpenLogic found that 41 percent of the iOS apps they analyzed included open source code in their construction, and that trend is likely to have continued across other app stores. What’s being concealed is the software freedom: It’s simply not being passed on to end-users, but rather ends at the developer. Rather than raise their heads above the parapet and admit to using open source — and pass the liberties it gave them on to their users — developers prefer to stay silent about the open source in their apps and to keep their source code private.

Three app store fixes What would fix this? First of all, developers may be able to avoid the more restrictive terms of app store agreements by sticking to weak copyleft code. Note that often doesn’t include the LGPL. While often considered a “weak copyleft” license, it is actually a strong copyleft license that incorporates a scope restriction setting a boundary on the project to which it applies. In mobile apps — especially on iOS — static linking is often used, and that elmininates the restricted scope of the LGPL, making the whole app subject to GPL requirements.

Second, app stores could take a more enlightened approach to open source software by harmonizing their terms to permit its use, by identifying the licenses used for apps, and even by providing links to the source code for apps where the developer requests it. This evolution is gradually taking place, and it’s possible we will begin to see more apps admitting to the debt they owe open source and extending software freedom to users.

Remarkably, a pioneer of open source-friendly terms for mobile appears to be Microsoft. Its Windows Phone Store Application Provider agreement (PDF) includes these two fascinating clauses:

4)d: … Your license terms must not conflict with the Standard Application License Terms in any way, except that if your Application or In-App Product includes FOSS, your license terms may conflict with the limitations set forth in Section 3 of the Standard Application License Terms, but only to the extent required by the FOSS that you use.

5)e: If your Application includes FOSS, (i) you must comply with all applicable FOSS license terms, including any source code availability requirements, and (ii) the Application must not cause any non-FOSS Microsoft software to become subject to the terms of any FOSS license.

That first clause is especially fascinating, and I interpret it as permitting even GPL software to be included in apps on Windows Phone — progress indeed for a company with such a strong, instinctive aversion to the GPL.

Finally, software freedom communities need to embrace commercial app stores. There’s been much caution until now, with suspicion that the closed and proprietary nature of the companies behind the stores is actually covert hostility to software freedom. I believe it’s time to change that, as I’ll be explaining next week at FOSDEM in Brussels. Communities need to recognize the power of app stores to extend the borders of software freedom. The platform doesn’t have to be an open source platform before the software running on it can deliver software freedom. We saw that with Windows, where Firefox and LibreOffice have both introduced millions to software freedom. The time to use app stores as a vector for software freedom is here.

This article, “How to make app stores open source-friendly,” was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.