LWN.net Weekly Edition for June 10, 2010

FSF takes on Apple's App Store over GPL

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.

Reaction

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. A 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)

Linaro seeks to simplify ARM Linux landscape

The ARM processor family is a complicated one, with many different variations, 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 release. 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 Linaro:

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 configuring 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 accomplished much.

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)

Playing with MeeGo 1.0

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 Moblin review 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 confusing inconsistency.

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 be finger-sized. 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 thing.

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...

Next page: Security>>