On July 16, Google quietly announced
that it has received its last shipment of Nexus One phones; once those have
been sold, Google will no longer sell the device. Commenters in the media
have immediately seized on this announcement as a sign of the failure of
Google's attempt to get into the handset business. That it might be, but
the real implications of this event may be different from the "carriers
rule" message found in the mainstream press.
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
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.
The pessimistic among us can be forgiven for concluding that the battle for
open handsets is being lost.
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
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
Comments (33 posted)
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
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:
It is entirely permissible for anyone to compile the game from source
and distribute it using their own distribution mechanism to people with an
iPhone device. There may be some barriers to distribution but these
barriers are entirely technical due to the "walled garden" nature of the
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:
I want recipients of my software to receive all the benefits that I have
received. I want them to be able to mod, share and experiment with the
software, and this is reflected in my preference for the GPL.
It's not really relevant *how* people are prevented from doing so, except
to the questions "Does it matter?" and "Can I do anything to prevent it?".
So, does it matter? As a software developer, a machine on which the owner
cannot choose what software to create and run is anathema. As a free
software developer, a machine which restricts free software is particularly
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:
essentially are saying that you want Battle for Wesnoth to be used as a
tool in the "Freeness" war against Apple, regardless of the wishes of the
Lead Developer of Wesnoth, the active developers of Wesnoth, or
the Wesnoth userbase itself. To me that seems selfish, not selfless. If
you have a low opinion of Apple and their restrictive licenses, which I
know I certainly do, there are plenty of other ways to go about expressing
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:
On one hand I feel an obligation to Kyle [Poole] since I told
him I felt he could distribute Wesnoth on the app store if he undertook
the substantial effort to complete the port. On the other hand, I am of
course obliged to all of the Wesnoth developers who have contributed
content under the terms of the GPL, and specifically those ones who feel
strongly that source code availability and other measures are not
sufficient to meet the terms of the GPL and thus that Wesnoth being
distributed on the app store is a very serious violation of the GPL.
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:
As a direct result of me spending more than 8 months fulltime working
on the iPhone port and publishing the source code, many other iPhone
projects have benefited from my work, not to mention improvements
which can be used for other Wesnoth branches such as Android, or
backported to the trunk. I think the spirit of GPL very much comes
through in the iPhone port.
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:
But disallowing independent distribution is... breathtaking. None of the
platforms I've ever coded for have done that, and it really scares me. I'm
sure you've thought about this far more that I have: am I overreacting?
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:
We do not see a
conflict between the GPL and the iOS, and we'd be outraged if you take
wesnoth away from us in order to strive for a slightly more
fundamentalist interpretation of the GPL. Removing our ability to run
the software we have built, on the platform we want, just because you
dislike the platform, flies in the face of everything the GPL has ever
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
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
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)
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.
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
Inside this week's LWN.net Weekly Edition
- Security: A Firefox add-on trojan; New vulnerabilities in freetype, Mozilla products, pcsc-lite, vte,...
- Kernel: The ghost of sysfs past; Fixing writeback from direct reclaim; Adding periods to SCHED_DEADLINE; Contiguous memory allocation for drivers.
- Distributions: REMnux 1.0: the malware analyst's playground; openSUSE, PC-BSD, YDL, DVL, Mandriva.
- Development: StatusNet releases a desktop client; GroupServer, Hatta, PacketFence, Transifex, ...
- Announcements: Women in free software; FSFE: 'Software Interactions' Document; Revising the MPL; Kuhn on Motorola; Neary on Open Core.