Leading items

The end of the road for the Nexus One

The Nexus One, of course, is an Android device. It is a quite nice handset, really, but the world is increasingly gifted with a wide choice of nice Android handsets. What sets the Nexus One apart is its relative openness; it need not be jailbroken, the bulk of its necessary software is free, and there is a variety of alternative Android builds to run on it. No other current-generation Android handset is so open, with the near-exception of the Motorola Droid - but Motorola has made it clear that the Droid's successors will not be so easy to work with. When the Nexus One is gone, if and until something else replaces it, the Android world will be more closed than it was before.

It is worth noting that the Nexus One is not going away entirely; it will be available alongside the ADP2 handset for developers set up as publishers in the Android market. But it will no longer be available as a mainstream consumer item.

The Nexus One has been widely portrayed as a commercial failure - and perhaps it is. It is an expensive device - on the face of it, rather more so than a shiny new iPhone 4, and it doesn't even come with a free case. The headline version only works well with the smallest carrier in the US, though an AT&T-capable version was eventually released as well. No US carriers sell it to their customers directly (your editor did just stumble across one for a mere €500 in a European Vodafone store). Promotion of the Nexus One was minimal and, seemingly, limited to Google's advertising network. Prospective customers have also figured out that, despite its towering strengths elsewhere, Google really just doesn't quite get the concept of customer support.

So the odds were rather stacked against this device from the beginning. One could hope that the prospect of an open device would be enough to motivate people to overcome the obstacles listed above and get a device like a Nexus One anyway. But the truth of the matter is that, at this point, openness at that level is not much use to most handset users. Your editor will confess that he still feels a certain childlike joy at the prospect of reflashing an expensive device that he depends on, possibly bricking it, then painfully restoring all of the settings and discovering all of the new bugs which have been added. It's the sort of adrenaline experience that others, perhaps, seek through horror movies, bungee jumping, investing in equities, or PHP programming. There is no accounting for taste, it seems. Not that many customers have a taste for the Nexus One experience, especially when even relatively locked-down Android handsets seem more open than many of the alternatives.

[PULL QUOTE: The pessimistic among us can be forgiven for concluding that the battle for open handsets is being lost. END QUOTE] The pessimistic among us can be forgiven for concluding that the battle for open handsets is being lost. The carriers determine which devices will be successful in the market, and they have absolutely no interest in openness. Customers are irresistibly drawn to heavily advertised, shiny devices with low up-front costs; they just do not see any reason to insist on more open devices or, even, freedom from carrier lock-in. Attempts to create a market in open handsets - Nexus One, OpenMoko - seem to go down in flames. By this reasoning, we may well all be using Linux-based handsets in the future, but the freedom that attracted many of us to Linux will have been lost.

By now, some readers are certainly protesting that this discussion ignores another mostly-open device: Nokia's N900. It's not clear that the N900 has been a commercial success either; your editor has yet to see one outside of a Linux-oriented conference. Still, the N900 might just point toward an interesting, less pessimistic future.

The MeeGo system remains a bit of a dark horse; it's arriving late to a well-established party. But MeeGo has some interesting attributes, including a real attempt to create an open, community-oriented culture and the backing of a pair of large companies with significant stakes in the outcome. Nokia and Intel are both watching the smartphone market happen without them; Nokia, in particular, very much needs to find a way back into the game. MeeGo appears to be part of the plan for that reentry, so considerable resources are being put into its development. As a result, MeeGo is quickly developing into something interesting.

If MeeGo handsets make their debut as "Android without all those annoying free Google services," they may find an unenthusiastic reception. But, just maybe, MeeGo can come in offering a better, more interesting experience which includes a higher level of openness. The N900 has already attracted a significant development community, one which is more tightly tied into the free software community as a whole. MeeGo, in a sufficiently open setting, might be able to engage the wider community in a way that Android has not, yet, succeeded in doing. If MeeGo takes off, some surprising things might just happen.

From the July, 2010 perspective, that all looks like a tall order. It depends on the availability of open handsets (which are currently nowhere in sight), solid software releases, a continued opening of the MeeGo project to the community, and a sufficient level of commercial success to keep the whole thing going. The odds seem daunting, but it's worth remembering that, not all that long ago, Android, too, was dismissed as a too-little-too-late offering in a crowded and maturing marketplace. There is also a wild card out there in the form of Palm's WebOS, now under HP's management. It may yet come to pass that, in the near future, the handset market will be dominated by competing, Linux-based devices where the strength of the development community - driven by the openness of the platform - is a key factor.

Comments (33 posted)

Wesnoth struggles with App Store's GPL incompatibilities

In light of the recent GPL compliance complaint made by the Free Software Foundation against Apple's App Store, which sells and distributes software for Apple gadgets, it was probably inevitable that other problem applications would surface. While there are various opinions on whether the App Store can legally distribute GPL-covered binaries—along with diverging opinions on what benefits, if any, the App Store provides to free software projects—it is clear that some people object to their GPL-licensed code appearing in the App Store. So it shouldn't come as a huge surprise that the port of the The Battle for Wesnoth for the iPhone/iPad, which was released last November, has run into some resistance.

As is usual for the wesnoth-dev mailing list, the discussion was largely polite and respectful, but there was clear disagreement. Rusty Russell raised the issue after a friend showed him Wesnoth running on an iPad: "That's great, except that it came via the Apple App Store. I didn't think that was allowed under the GPL?". He pointed to the FSF's blog post about GNU Go, and noted that he was "uncomfortable with Apple's restrictions on the devices after they sell them".

Wesnoth lead developer David White responded that, unlike GNU Go, Wesnoth had been ported to Apple's devices with the explicit endorsement of the development community. He and the other developers, including Kyle Poole who did the port, believed that the port was "acting within the GPL" because the source was available and:

White went on to describe the benefits that he saw from putting the application into the App Store: revenue for the project, which is being used to fund art development, and raising the profile of FLOSS gaming. He noted that it helped users become more aware of FLOSS games, but also made other free software game projects aware of the App Store as a distribution platform. Russell didn't find those to be particularly compelling arguments in favor of distributing Wesnoth in the App Store, in fact he found the opposite to be true.

Because the App Store EULA imposes restrictions on what users can do with the binaries they download, the FSF and others believe that it runs afoul of the "further restrictions" clause in section 6 of the GPL. As Russell points out, the "walled garden" that Apple is creating violates his understanding of users' rights under the GPL:

In addition, Russell is skeptical that users are really being exposed to free software gaming, instead they are just finding "a great game for $5". He also believes it's "self-defeating" to strengthen the Apple platform by putting more free software on it. But others clearly disagree. Patrick Parker noted that it was not a secret that an iPhone port was taking place, as it had been discussed on the forums and on IRC, and that a complaint at this late date was "selfish". Furthermore, he was unhappy seeing Wesnoth used as a weapon:

Russell agreed with some of that, saying that he worked on Wesnoth because it aligned with his selfish goals: "I want to encourage Freeness, and helping Wesnoth seemed like a good way to do that. Or, if you prefer, 'a tool in the "Freeness" war'." But he also acknowledged that others had different goals, which is where the license comes into play: "that's why we have a license, and a common understanding of what it means".

The FSF's complaint, which raised the license issue for the first time, came well after the Wesnoth port was completed after some eight months of work by Poole. That puts the project, and White in particular, in an uncomfortable position. His "main concern" when Poole approached him about porting the code was to ensure that the full source code would be available. The source is available, but White is, to some extent, stuck between a rock and a hard place:

Poole describes the port as having an impact that is very much in keeping with the ideas behind the GPL, even if Apple's EULA tries to hinder it:

But the power grab enabled by Apple's EULA is sweeping, which is what concerns Russell: "AFAICT, the device is designed not to allow the freedoms the GPL tried to guarantee." By not allowing Wesnoth binaries to be redistributed, Apple has gone further than others, he said:

His question remains unanswered, at least directly, but certainly some see the arguments made by Russell and the FSF as too rigidly interpreting the GPL. For example, Richard Kettering resolutely defends what he perceives to be the interests of the artists and musicians in the project:

The irony of that last sentence seems to have escaped Kettering, but Russell is quick to point it out: "Generalize the words 'just because you dislike the platform' to 'for any reason' and you've summed up the problem with these devices very well :("

White has suggested that a list of Wesnoth contributors be created from the Subversion logs, and that each be contacted to be made aware of the situation. Any that are willing can make a licensing exception to allow their contribution to be used in an application distributed through the App Store. Those that aren't willing, and Russell and others may well be in that camp, would have their contributions removed from the App Store version.

Exactly what form that exception would take is up in the air. Paul Ebermann is concerned that wording it will be difficult, but White disagrees as he thinks a specific App Store exception can be made. Currently, the plan is to convene an IRC meeting of all concerned project members to discuss the problem. Decisions on license exception wording, as well as a plan to remove any content from contributors unwilling to agree, will presumably be worked on as part of that meeting.

Apple does provide the means for applications to present their own custom EULA, so Poole looked into the possibility of using the GPL as Wesnoth's EULA. But, Apple has closed off that potential remedy as well: "Apple states that any custom EULA must meet their 'minimum terms' which can't be more permissive than their default." But, as Gabriel Morin pointed out, there are even worse terms in the Apple's iPhone Developer Program License, which Poole was required to sign, but he "probably didn't mention it since the agreement prohibits making public statements about it". Morin doesn't see how it is at all possible to reconcile the GPL and that agreement.

This is clearly a clash between a license intended to ensure user freedoms and a company hell-bent on ensuring that it is in complete control of what can run on the devices it sells. There may be ways to remove code or content from the Wesnoth codebase, such that all that remains has some kind of license exception to allow it to run on iPhones and iPads, but the question will still remain: does working around Apple's draconian requirements really help the cause of free software? Opinions clearly vary, but it is something our communities will continue to struggle with.

One clear lesson from all of this was noted by Parker: "However, if I ever start my own open source project, I will probably require copyright removal or assignment as a precondition to inclusion (much like the FSF does with its own programs)". Had a copyright assignment to a Wesnoth non-profit been required for all contributions, all of the App Store licensing problems could have been avoided, as the copyright owner could have issued a separate license. Whether as vibrant a community would have arisen around this hypothetical "Wesnoth with copyright assignment" project is an open question.

Apple is unlikely to change its terms regardless of what Wesnoth decides. Its walled garden is working very well for it and few, if any, of its customers are clamoring for a change. While it is very cool to see a free software game like Wesnoth running on these über-trendy gadgets, it is a bit hard to see how it brings more folks into the free software world. On the other hand, it's hard to see how denying the iPhone/iPad universe access to Wesnoth is going to make a difference either. It's really up to consumers to recognize—and clamor for—devices that respect their freedoms. So far, that just hasn't happened.

Comments (58 posted)

Ubuntu's font beta sparks discussions about open font development

Canonical recently launched a "beta" testing program for its still-in-development Ubuntu font. The font is provided through an Apt repository accessible only to Ubuntu Members — individuals who actively contribute to the project, apply, sign a code of conduct, and are approved by community membership boards. The font is intended for screen usage as the default interface font in the next Ubuntu release, covering the extended Latin-A, Latin-B, Greek Polytonic, and Cyrillic character sets.

The new font is part of Canonical's branding and visual identity refresh first introduced with Ubuntu 10.04. Canonical contracted development of the font to type foundry Dalton-Maag, who is scheduled to deliver several weights of the font (including bold, italic, and monospace) in time for the October release of Ubuntu 10.10. Currently, only the regular weight is available for testing. The font name is "UbuntuBeta" inside the TrueType binary, though it may be renamed before final release.

Non-members can test the font via a web application that uses the @font-face construct in CSS 3, rendering user-provided sample text at any size from 6 to 36 points. An account on Ubuntu's Launchpad.net service is required to use the web application, though, because the tool ties into Launchpad's bug tracking system. Canonical says that the visual design of the font is complete, but is soliciting feedback from users about kerning, hinting, and other potential rendering problems. The web application allows users to select problematic glyphs in the rendered text and submit bug reports against the project.

Criticism of "closed" beta

The company's decision to restrict the current beta only to Ubuntu Members has drawn its share of ire, however. Maia Kozheva posted a blog entry styled as a letter to Canonical criticizing the restricted-access beta as "contrary to the entire spirit of free software." Several commenters at Kozheva's blog and on general news sites covering the launch agreed. Kozheva also expressed skepticism about the "open" license Shuttleworth said the font would be published under, which has yet to be specified much less applied to the release.

Canonical's Jorge Castro commented (the third comment on Kozheva's post) that the font was made available in a limited test because of its incompleteness, saying "font foundries who make fonts don't like beta fonts to spread because once they do they feel it's hard to track down who has the font and update that." He also addressed Kozheva's concern that the as-yet-undetermined license for the font would not be sufficiently free, noting Ubuntu's policy to ship only free software in the "main" Apt repository.

At one level, font foundry's reluctance to release pre-1.0 fonts for public consumption is understandable; no one enjoys widespread dissemination of buggy work. But the suggestion that fonts are intrinsically different from other software in this regard does not stand up to examination. After all, people have argued in the past that particular niches of software or types of project do not fit the standard "release early, release often" open source development model, and should be excused.

Those wanting to be excused tend to conjure up the same spectre: that early releases will confuse and frighten end users, hurting them and endangering the project. But that bogeyman ignores years of successful open source development in all areas of computing, and there are examples of successful projects for each niche claiming an exception.

To its credit, despite Castro's comment, Canonical does not seem to be motivated by a desire to keep the Ubuntu font secret prior to its official release — the CSS-based testing tool and call for bug reports are evidence enough of that. Rather, the fundamental issue is more likely to be that the font is a commissioned work from a third-party, and the company may not own it until it is delivered in final form by the contractor. That would be in line with Canonical's current lack of a license selection, but, apart from corporate lawyers, there is simply nothing to prevent the company from announcing what the license will be.

Context

Canonical's font commission from Dalton-Maag follows the pattern established by the Liberation and Droid font sets in years past. Both Liberation and Droid were commissioned by Linux distributions (Red Hat and Google's Android, respectively) from Ascender Corporation. Although both were released under open source licenses when complete — Liberation under the GPL with a font-embedding exception clause, and Droid under the Apache license — neither was made available for beta testing during its development.

The Open Font Library (OFLB) project's Dave Crossland said that he believes "libre fonts ought to be developed fully public from the start," but that in its historical context, the Ubuntu Beta program is a welcome innovation and ought to be applauded. To the best of his knowledge, he said, no proprietary font companies release beta testing versions of their fonts — although some custom fonts designed for print publications undergo ongoing revision, which has a similar effect regarding feedback from readers.

In addition, Crossland added that the CSS font testing web application deployed for the Ubuntu Beta font is itself an impressive development, and makes collecting rich bug reports easy.

Challenges for open font development

Fonts certainly can be developed in the open, as OFLB's library demonstrates. Practically speaking, however, most fonts released under open licenses are not developed using public source code repositories, version control systems, and issue trackers. Crossland observed that (apart from operating system default installs) fonts are historically installed by users as binaries, rather than through package repositories that facilitate updates. That has long been the case on proprietary operating systems, and is common practice for commercially-purchased and "free font" downloads by Linux users. "Instead we drag'n'drop binary files into system font folders by hand, and of course we never check back to see if there are updates for that font we installed and mostly forgot about." As a result, fonts do not receive the type of feedback from users that helps them to evolve.

Changing this development process is something that OFLB has been discussing in recent months, including planning for a revision to the project's public web site. Nicolas Spalinger, co-author of the Open Font License and member of the Debian pkg-fonts team, helped develop an "open font design toolkit" package now available in Debian and in Ubuntu that includes not just the design tools, but version control, diffing and patching utilities, and skeleton files for maintaining change logs.

Equally important to open font development is enabling users to make contributions. As it stands today, it is not easy for end users to contribute back to a font. Source code packages are available for several open fonts, but there is no packaging standard between distributions, and sometimes not even within a distribution. Some source packages contain .SFD sources for the font editor FontForge, for example, but not build or installation scripts. Ubuntu's graphical Apt front-ends Synaptic and Ubuntu Software Center do not even allow browsing or downloading source packages.

To non-developers — who constitute the largest group of potential font contributors — editing fonts remains effectively out-of-reach. It is not a hypothetical concern, either. Several readers commented on the Ubuntu Font Beta announcement that they would like to contribute additional characters or alphabets to the font; without some changes, it will be hard for them to do so.

Clearly, the challenge of opening up fonts to the same standards of software freedom common in other packages is not unique to Ubuntu or Debian. Other distributions are showing signs of taking the subject more seriously; Fedora, notably, has an active font Special Interest Group (SIG) packaging open fonts in binary and source form. While the "members only" beta program Canonical unveiled for its font commission raised some objections, it needs to be seen in context, as one small move on a longer trajectory of opening up fonts.

Comments (9 posted)

Page editor: Jonathan Corbet
Next page: Security>>