Apple's App Store for iPhone, iPod, and iPad devices has no shortage of critics, from the delays in application approval to the seemingly arbitrary removal of previously-approved applications. The Free Software Foundation (FSF) recently took on yet another problem with the distribution channel when it contacted Apple to pursue a GPL compliance problem with a GNU-copyrighted game. Apple evidently found it easier to remove the game in question than to alter its App Store policies, but the debate has sparked a discussion about free software on Apple's otherwise closed devices.
The trouble began with a GNU Go for the iPhone game, submitted to the
App Store by Robota Softwarehouse. GNU
Go for the iPhone is a port of the original GNU Go — a program for playing
the game of Go
including an AI opponent — which is an official part of the GNU project. At some unspecified date, the FSF contacted both Robota and Apple to ask them to come into compliance with GNU Go's license, the GPLv2. Robota was violating the license by not providing access to the source code of the game, and Apple was in violation for several reasons, according to FSF License Compliance Engineer Brett Smith. Fearing that, in response, Apple would simply remove the GNU Go game from the store without explanation, the FSF posted a blog entry on May 25 describing its case. That fear was evidently well-founded, as Apple pulled GNU Go for the iPhone on May 26.
Smith followed up the original post with a more detailed explanation on May 27. In it, he says that the particular license violation that FSF brought up with Apple was section 6 of the GPLv2, which states that a redistributor of the licensed program may not impose further restrictions on the recipients to copy, distribute, or modify the program. Apple's App Store terms of service do impose several restrictions, such as limiting usage of the program to five devices approved by Apple.
David "Lefty" Schlesinger criticized the FSF's action in a string of
posts on his personal blog, starting by challenging
whether FSF would engage in similar compliance actions against other mobile
application marketplaces, such as Android's or Windows Mobile's. He
followed that up with a second
post rejecting the idea that Apple would be considered bound by the
terms of the GPL, comparing the App Store to general "file download" sites
such as FileHippo that host binary packages of free software but do not
also host source code. Finally, he asserted in a third
post that Apple could not be held to the terms of the GPL at all, because it would qualify for protection under the
"safe harbor" provisions of the Digital Millennium Copyright Act (DMCA).
Debate over the entire chain of events can be found on every outlet from
Slashdot to Identi.ca, including some lengthy exchanges in the comments on
Schlesinger's blog posts. Examining Schlesinger's arguments, it is
impossible to predict whether FSF would (or has) pursued GPL compliance
action against other application markets, both because the FSF only acts on
GPL violations for which it owns the copyright to infringing code, and
because most compliance actions take
place in private. Smith stated that the FSF only publicized the GNU Go
case to forestall speculation that might result if Apple silently pulled
the application as the FSF predicted it would.
On the second post, it seems quite clear that the GPL does
apply to Apple as well as to FileHippo or any other site that hosts
GPL-licensed code. Apple accepts the code from the developer, then
redistributes it in the App Store; that triggers the license. On the other hand, section 3(c) states that
noncommercial distribution by those who received the program as an
executable can comply with the source code requirement simply by providing
the upstream distributor's source code offer. Whether a zero-cost game in
the App Store qualifies as "noncommercial" is open to interpretation.
download-only site like FileHippo should be in compliance provided that its binaries are unaltered; if the upstream source of the binary did not include a compliant source code offer, it would be the upstream source that is non-compliant.
But there is no similar exception in section 6 that passes the buck upstream. Apple's App Store terms-of-service definitely impose restrictions on the use of GNU Go for the iPhone, and the wording of section 6 is simple: "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
Schlesinger and other commenters seem taken aback by the scope of the definition of "distributor," saying it would be ludicrous to hold Best Buy or other brick-and-mortar stores to the GPL if they sell boxed copies of free software. It is certainly an inclusive definition, but it is not as bad as the hypothetical Best Buy scenario implies; a big-box retail store could reasonably claim
ignorance to the contents of a prepackaged product, which Apple with its
per-app-review process cannot, but, in any case, a retail store is not able to
impose additional restrictions as described under section 6.
As ChillingEffects.org explains in
detail, the "safe harbor" provision of the DMCA applies only to
service providers, defined as "an entity offering
transmission, routing, or providing connections for digital online
communications, between or among points specified by a user, of material of
the user's choosing, without modification to the content of the material as
sent or received" or "a provider of online services or network
access, or the operator of facilities thereof," further limited to
systems that provide "conduit communications", "system caching", "storage
systems", or "information location tools". Considering those definitions,
Apple's App Store simply does not appear to qualify for protection. But even if it did, Smith said, that only limits Apple's liability, it does not excuse them from compliance with the GPL. Apple "would still have to make the same choice about whether to come into compliance with the GPL, or cease distribution altogether."
Spreading the word
The big unanswered question is whether or not the FSF's action does more harm than good in the effort to spread free software. Schlesinger says repeatedly in the comment threads (as do others on other sites) that it does more harm, preventing users of the iPhone from using free software and being exposed to free software ideals. The FSF, for its part, suggests that there is little exposure to free software ideals when the terms-of-service restrict the software to begin with.
In the end, it is probably a judgment call; certainly technical restrictions of the iPhone platform would prevent users from exercising freedom to modify and redistribute GNU Go for the iPhone even if they had the source code in hand. Would they nevertheless learn to appreciate software freedom more?
The other charge made against the FSF in this case is that it singled
out Apple as a public example solely for the sake of publicity. That is
speculative, of course. FSF has targeted Apple for criticism before, as it
has Microsoft, but as Smith explained in the first blog entry, it talked to
Apple in private first — as it has with Robota, who still does not seem to have posted the source code to the problematic game. Even if one does not take FSF at its word (that the public discussion of the case was meant to preempt uninformed speculation), it has had one positive effect: it has gotten the community talking about free software licensing and mobile application distribution, a subject that will only grow in importance in the coming years.
Comments (87 posted)
The ARM processor family is a complicated one, with many different
leading to large numbers of separate sub-architectures in the Linux kernel.
A quick glance at the ARM directory in a recent kernel tree
shows nearly 70 different sub-architectures, each corresponding to a
different CPU or system-on-chip (SoC). That complexity has made it
harder to develop new products for new or existing ARM devices.
A new organization that was formed by six silicon vendors, Linaro, seeks to simplify that landscape,
and allow easier—faster—development of ARM-Linux-based products.
Linaro was announced on June
3 as a non-profit company founded by ARM, Freescale, IBM, Samsung,
ST-Ericsson, and Texas Instruments that intends to "provide a
stable and optimized base for distributions and developers by creating new
releases of optimized tools, kernel and middleware software validated for a
wide range of SoCs, every six months." That six-month schedule
aligns with Ubuntu's—the first release is due in November, one month
after Ubuntu 10.10—and Canonical will be heavily involved in the effort.
Linaro already has a project in
Launchpad, Canonical's software collaboration platform, and it will
seemingly take the place of Ubuntu-ARM.
The focus will be on the low-level plumbing for ARM-based systems: the kernel,
development tools, boot loaders, and graphics. The Linaro FAQ and other pages on the
web site make it clear that Linaro is not planning on creating a new
distribution. It is, instead, pitching in on upstream projects to simplify
and optimize for ARM systems. It is not a new distribution, but clearly
the hope is that various distributions will adopt the Linaro contributions.
The company lists current mobile distributions as potential
benefactors of its efforts. Android, MeeGo, LiMo, and Ubuntu are
specifically mentioned as mobile ARM distributions that might benefit from
the work Linaro is planning to do. Because the work will be done in
conjunction with the upstream projects, any other existing or new distribution
can also make use of the improvements.
In addition, Linaro touts its benefits to consumers. By reducing the
complexity for device makers, it will be "enabling exciting
innovative products to come to the market quicker". Focusing on
power consumption will also result in devices that "have longer
battery lives or slimmer cooler designs". Linaro clearly wants to
maintain—increase—the level of ARM adoption in mobile devices.
Linaro will be well-funded, with a budget said to be tens of millions of
dollars, much of which will pay for 80 employees. There are several levels
of membership in Linaro, with two paying classes, Core and Club, which each
provide money and engineers to the organization. For small organizations
or individual contributors, there is the free Community Member class.
There is a rather elaborate organizational structure
that governs the company, as well as a management team in
place. Based on all of that, it seems clear that Linaro wasn't just thrown
together quickly, but
has been in the works for some time.
There are already specific plans for what will be contained in the upcoming
Canonical's Linaro release manager, Jamie Bennett, looks at the
plan for Linaro 10.11 on his blog. There he also provides some more detail
on the fragmentation in the Linux ARM world that led to the formation of
Kernels, boot loaders, and to a lesser extent middleware are being worked
on in isolation with little in the way of standards and a common
direction. This is scary for those who are used to working in the Intel
world where one kernel and one boot loader will pretty much work on all
compatible devices. To really push ARM devices into the standard spaces
Intel currently [enjoys], something needs to be done.
That something is laid out in a detailed release document on
the wiki. The tasks are broken up into four areas: Kernel, Graphics and User
Experience, QA and Validation, and Infrastructure, with Linaro-specific as
well as related Ubuntu tasks listed. Using device trees
to describe different ARM hardware, which could reduce the complexity of
Linux for the platform, is high on the list. While some ARM hackers are
not sold on device trees, a recent linux-kernel discussion about the
proliferation of ARM configurations would indicate that
Linus Torvalds, at least, is interested in seeing some kind of complexity
reduction for that architecture. If Linaro can work with the upstream
kernel developers to find a solution—device trees or
something else—to that problem, it will have
There are other things on the agenda for the 10.11 release including
standardizing and unifying the telephony stack for the platform, making Qt
fully functional on ARM, optimizing web browsers for the architecture, and
selecting the "best toolchain for ARM hardware". Overall, the
list of planned achievements for the five months before the release is
quite ambitious. Whether all that can be completed by a brand new
organization—even with a great deal of Canonical
know-how—remains to be seen. In the end, even completing a big chunk of it would
be quite an accomplishment; presumably there will be 11.05 and further
releases to fill in any gaps.
In many ways, Linaro is further proof that Linux is winning the
battle for which OS will run on consumer electronics and other embedded
devices. ARM chips are the dominant embedded Linux platform these days,
but Intel has been targeting the low-power arena with its Atom processors.
Linaro certainly looks like an effort to ensure that ARM-based devices
maintain their lead in the embedded Linux world. It should be an
interesting battle to watch.
Comments (17 posted)
The MeeGo project - the result of the merger between Moblin and Maemo - released
version 1.0 of its core platform on May 25, accompanied by the first
iteration of its "Netbook user experience." Your editor, who happens to
have a netbook system sitting around, decided to give this release a try to
see what has happened since the
written last November. While the overall feel of the
system is quite similar, there has also been some real progress; MeeGo
feels more like a finished product than Moblin did.
The overall user interface concepts laid out by Moblin have not changed
much in the merger with Maemo. There is still a home screen meant to
provide access to recently-used activities, be they web pages or
communications with others. The line of icons at the top still shows what
the MeeGo developers think people will want to do with netbooks: talk to
people, browse web pages, play music, etc. The quality of the graphics and
animation have improved somewhat, but the basic interaction model is what
Moblin had before.
There is an interesting distinction between running an activity from the
top icon bar and running an application. Applications run in "zones,"
which are essentially virtual desktops which hold one window each. Moving
between zones is done quickly enough by putting the pointer at the top of
the screen, selecting the zones icon (yielding a display of the active
zones), then picking the new destination;
it's an experience similar to holding down the "home" key on an Android
system. But an application run from the top bar (the music player, say, or
the web browser) is treated differently; it has no zone and cannot be
jumped into and out of that way. Your editor finds this to be a bit of a
Speaking of web browsers, MeeGo now uses Chrome (or Chromium, one can
choose at download time) for web access. Chrome is, of course, a
reasonably mature and quite functional browser. The "Mozilla headless"
mechanism used with the Moblin browser worked, but not all users were happy
with the experience; Chrome, perhaps, will be better received.
While most things work nicely, one occasionally encounters a rough edge.
Your editor was able to crash the desktop by playing with an external
monitor. MeeGo lets the user choose between the built-in or an external
monitor, but does not want to run both at the same time - not even in
mirrored mode. One other thing that has jumped out is that options which
are toggles are controlled by a widget which looks like a sliding switch.
There are no labels, though, so it's not always obvious whether the option
is enabled or not.
The big sliders are typical of the way the MeeGo interface looks, though;
buttons and such are big. Netbooks tend not to have touchscreens, but this
user interface is clearly headed in the direction where everything has to
The interface is also still very much GNOME-based, despite MeeGo's plan to
move over to Qt. Mail is handled by Evolution, the media player is
Banshee, etc. Perhaps that will change over time; evidently the tablet
user experience is more Qt-heavy.
While exploring options for customizing the top icon bar, your editor
stumbled across "gadgets," a relatively hidden feature that, perhaps, shows
where the MeeGo developers plan to go. Gadgets are little applications
which can be placed on a special screen; there are weather monitors, silly
games, slideshow applications, etc. The interface for choosing them is
awkward (browse through all 1000 of them in some strange order, four at a
time) and there doesn't seem to be a way to place them somewhere useful, like
the home "MyZone" screen. But it has the look of the beginnings of some
sort of "application store" mechanism which is separate from the normal
package management system used by MeeGo.
There is one other difference between Moblin and MeeGo that your editor has
noticed: Moblin was a multi-user system with the ability to set up multiple
independent accounts. MeeGo, instead, has a single account (called "meego,"
but one has to look hard to find that out) and no provision for creating
or logging into any others. MeeGo devices, it seems, will be more like
phones than Linux computers; they are highly personal devices that one does
not ordinarily share.
Perhaps that is the future of Linux on the desktop - at least, Linux on the
relatively small desktop. Like Android, it's not the sort of Linux
experience that we are used to, though MeeGo is far closer to "traditional"
Linux than Android is. But perhaps it's an experience that will bring in a
new set of users; once they get used to this environment, the full Linux
experience will be there for them to discover. That should be a good
First, though, MeeGo needs to get out there on devices and into the hands
of users. Evidently a number of MeeGo-based devices were on display at
Computex, which is a start, but there are not a whole lot of deployed systems
out there. So MeeGo is far behind other systems, including Android, which
are aiming for very similar markets (though it is ahead of ChromeOS,
which won't have a stable release for a few more months). Coming from
behind in a highly competitive market is a hard thing to do, even when the
market is expanding. But MeeGo has a lot of resources behind it and a lot
of thought going into its design. Even if it's a bit of a dark horse, it's
worth keeping an eye on.
Comments (24 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Mozilla's Plugin Check; New vulnerabilities in bind9, kernel, OpenOffice.org, perl,...
- Kernel: "Desperate Androids"; Another OOM killer rewrite; Writing a WMI driver
- Distributions: OpenSUSE searches for its strategy; Ubuntu 10.10 Alpha 1 released; Shuttleworth on Linaro; Robby Workman interview; Fedora 14 features.
- Development: A look at GNOME Shell; Konversation, LLDB, Python 2.7, Rockbox, Scribus, ...
- Announcements: KDE e.V. offers supporting memberships; The Linaro consortium; Next3; WebM gets a new license; Geist: The Canadian Copyright Bill...