LWN has visited the issue of trademarks - and the Mozilla corporation's
trademarks in particular - a number of times over the years, but not
recently. This topic recently resurfaced on the Fedora development list,
so it seems like time for another look. It is clear that heavy-handed
trademark policies do not sit well with some members of the community, but
are trademarks really a threat to free software?
Fedora's policies are not normally forgiving of packagers who want to
bundle their own versions of libraries. Having multiple copies of
libraries bloats the size of the distribution and makes it hard to fix any
security problems in those libraries. This policy has, at times, made life
difficult for packagers trying to get a new program (with a bundled
library) into the distribution; such packagers are usually required to make
the program work with the system's core libraries. There are exceptions,
though, with Mozilla-based packages (Firefox, Thunderbird, and xulrunner)
being at the top of the list.
Mozilla, in turn, is adamant about its right to bundle its own libraries.
The project's recent rejection of
a patch allowing the use of a system's version of libvpx was the immediate
cause of the discussion in the Fedora community. Mozilla developer Chris
Pearce justified the decision this way:
Sorry, we won't take this. We prefer to ship our own copies of the
media libraries, as if necessary we can cherry-pick a critical
security fix and push out a release quickly, rather than relying on
the distros to update their libraries. We can guarantee the safety
and stability of our libraries this way.
Firefox is free software; Fedora is free to modify its build to
make Firefox use Fedora's own libvpx. The catch, of course, is the
trademark policy: if Fedora makes this kind of change, it can no longer
call the browser "Firefox." That is a restriction which rubs some developers
the wrong way. Some users have gone as far as to claim that trademark restrictions make the
If the owner of the trademark doesn't grant a license that is
compatible with a free software license, then the software is non
free. Linus doesn't go around telling people they can't
redistribute a modified linux kernel. His only restriction on the
linux trademark is that it is used to label things that use the
Such users have been calling on Fedora to drop Firefox and take the
iceweasel route. It is worth noting that the people asking for this change
are not the people who would have to do the work. And it seems that the
amount of work would be considerable. In fact, we're told that Fedora's
maintainers cannot really keep up with Firefox etc. now; they have little
appetite for taking on more work to get away from the trademark policy.
As Rahul Sundaram put it:
Ignoring upstream and patching without consent is only feasible if
you have the amount of resources to do a good job with that.
Fedora doesn't have that.
In fact, according to Adam Williamson,
Fedora's policy with regard to Firefox is not driven by the trademark
Practically speaking, [iceweasel] would add an extra burden to the
maintainers, who already do not have enough resources to deal with
all the issues. Again, the reason we don't carry non-upstream
patches in Firefox has nothing to do with the branding issue. It's
because we don't have the resources to maintain non-upstream
patches in Firefox.
This claim was not accepted by all members of the Fedora community. Toshio
I wish people would stop repeating this particular bit of
justification for the issue of bundling libraries. I can see it
for other suggested patches for firefox but in the case of bundled
libraries, this is work that we require of all packages because
there's security ramifications for our product, the Fedora
distribution by not unbundling.
One suspects that, in the absence of the trademark issue, there would be
more pressure within Fedora to simply fix the bundled library issue in
Fedora. But nobody wants to take on the extra burden that would be
imposed by forking Firefox - even if it's a fork which simply tracks
upstream with a few added changes.
Beyond that, it has been noted that Fedora, itself, has a similar trademark
policy in place. Maintaining that policy while protesting Mozilla's seems
a little inconsistent.
Trademarks often seem at odds with the ideals of free software; they may
not place restrictions on what can be done with the code, but they
do restrict the combination of the code and a name. Many people in
the community (and here at LWN) have worried that this control could be
used to restrict the community's freedom in unwelcome ways. Clearly, some
people not only fear that it could happen, but that it is happening now.
That said, we now have roughly ten years of experience with the combination
of trademarks and free software. That experience has certainly proved
irritating at times. But it has not proved disastrous. In the end, the
power of a name is not as strong as the power behind the freedom to fork.
Losing the XFree86 name did not hinder X.org, and the OpenOffice.org
trademark has not stopped LibreOffice. After this much time, it is
tempting to conclude that free software and trademarks can live with each
other - or, more exactly, separating the two is done easily enough when the
need arises. Obnoxious trademark policies are still worth protesting, but
we need not fear that they threaten free software as a whole.
Comments (58 posted)
Your editor's iRiver H340 music player attracts stares in the crowded
confines of the economy class cabin; it is rather larger than many newer,
more capable devices, contains a rotating disk drive, and looks like it
should have a smokestack as well. But your editor has continued to nurse
this gadget for a simple reason: it is no longer possible to buy anything
else like it. The device is open, has a reasonable storage capacity, and
is able to run Rockbox
. It is, thus, not
just running free software; it is far more functional and usable than any
other music player your editor has ever encountered. These are not
advantages to be given up lightly.
Why can't the H340 be replaced? Flash storage is one of the reasons. A
solid state disk makes obvious sense in a portable music player, but an
immediate result of their adoption was a reduction in the storage capacity
of the players. Your editor, who has had a lot of time to accumulate a
music collection, does not want to select the music he will hear prior to
leaving the house. Some time recently spent in Akihabara shows that
capacities are slowly growing, but there was only one non-iPod device on
offer which matches the H340: a pretty Sony player which does not support
useful formats (e.g. Ogg) and which is certainly difficult to put new
firmware onto. Needless to say, there is no Rockbox port for that Sony
player. In conclusion: there is still nothing out there as good as the
H340, at least for your editor's strange value of "good."
There are a couple of conclusions to be drawn here: (1) the market for
personal music players may well be in decline, so newer, better players are
not coming as quickly as one might like, and (2) the players
which continue to exist are increasingly closed and unlikely to run
discouraging trend has been evident for a while, but there is hope. One of
the reasons for the apparent decline of standalone media players must
certainly be the growth of smartphones. A decent phone is able to run a
music player; why carry two devices when one will suffice? Unfortunately,
the music players available on most of these devices leave something to be
desired. Even if they handle a wider variety of formats (as Android-based
players tend to), they lack other important functionality: gapless playback
and bookmarks being at the top of your editor's list. Using a phone-based
music player after becoming accustomed to Rockbox feels like going several
Enter the Rockbox Android
port, which is actually a subset of the "Rockbox as an application"
port. The core idea behind this port is that the days of standalone media
players might just be coming to an end, while the days of much more
powerful mobile computers are just beginning. Contemporary mobile systems
can run a real operating system; they are thus open to the installation of
specialized applications. The ability of Rockbox to run on a variety of
hardware platforms is valuable, but what really distinguishes Rockbox is
the intensive attention that has been put into making it be the best media
player available. So it makes sense to think about dropping the hardware
support and hosting Rockbox as an application on top of another operating
Let it be said from the outset: Rockbox on Android is far from being ready
for general use, and its developers know it. For those who want to try it
out, there are prebuilt Android packages for a few screen sizes, but users
are cautioned against expecting too much, and the developers don't even
want to hear about bugs encountered with the prebuilt versions. Anybody
who seriously wants to try Rockbox on Android needs to build it from
source; if nothing else, the target's display size must be selected at
build time. The build process is not trivial - one must install the
Android SDK and native application development kit - but it is not
particularly painful either. The end result is a rockbox.apk file
which can be installed on a convenient handset.
Running the application is likely to be most confusing for the unprepared
user, though. The traditional top-level Rockbox menu appears on-screen, but the
result of tapping a menu entry is not what one would expect; indeed, the
application's response to touch events seems to be nearly random. After digging
in the forums, your editor stumbled across this
bit of helpful advice:
Imagine that your screen is a 3x3 grid, where the middle is used as
the selector, left-right-up-down are used as cursor keys. The other
directions have special functions in some screens, e.g. in Now
Playing screen with the upper left you can access some playback
In short: the Rockbox user interface was not designed with touch screens in
mind, so the developers have partitioned up the screen and mapped the
pieces onto the arrows and buttons found on a typical old-school media
player. Without putting any indication on the screen that it has been so
divided. To say that this decision violates the principle of least
surprise is a bit of understatement, but, once the nature of the interface
has been understood, Rockbox can be made to work as expected. Your editor
is listening to music from the Android Rockbox client as this is being
As it turns out, deep in the settings menu there is an option to switch the
touchscreen interface to "absolute mode." That causes taps on menu entries
to do the expected thing. There is still a lot of work needed to make the
interface truly touch-friendly, though - or even to make basic things like
the "back" button function properly. It is sometimes possible to get stuck
in screens where exit seems to be impossible. The "while playing" screen
operates in strange and mysterious ways. Fixing all of this will require a
bit of time by a determined user-interface developer, but there should not
be any fundamental challenges involved.
Unsurprisingly for a port in such an early state, there are a number of
other glitches and shortcomings waiting to be discovered. Some
functionality has not yet been implemented - support for the FM radio (if
present) and audio recording top that list. Attempts to use the database
feature lead to "panic" messages and/or locked screens. The plugin feature
does not appear to work at all - but it is also far from clear that plugins
make any sense in the Android environment. Rockbox has its own idea of the
playback volume which is separate from the Android system's. And so on.
That said, the Rockbox-on-Android developers have made it clear that this
idea can work. The hard part appears to be done; now it's just a matter of
tying up a fair number of loose ends. OK, it's a matter of tying up a
lot of loose ends.
So, one might ask, is the H340 going into a well-earned retirement? Not
quite yet. You editor must still wait until he has a handset with
sufficient storage to hold at least a significant part of the music/podcast
collection; the Nexus One does not qualify - though an SD card upgrade
would make some real progress in that direction. There is another important
requirement, though: a media player must have sufficient battery life to
get through a long transoceanic flight without leaving the traveler
phoneless at the other end. An overnight test showed that a fully-charged
Nexus One in airplane mode can run Rockbox continuously for about
18 hours - not bad, but not quite enough for a long trip where the
phone will be used for purposes other than just playing audio.
So the H340 will likely have to rock on for a little longer. But the
writing is on the wall: there will probably not be a standalone replacement
for that faithful piece of hardware. Regardless of whether your editor's
next phone runs Android, MeeGo, or something else entirely, it appears that
there will be a highly capable, GPL-licensed music player application
available for it. It's hard to complain about that.
Comments (39 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Questions about Android's security model; New vulnerabilities in freetype, krb5, MySQL, PostgreSQL, ...
- Kernel: Trusted and encrypted keys; Two ABI troubles; Solid-state storage devices and the block layer.
- Distributions: Fedora defines its vision; Smeegol, Ubuntu 10.10 RC, CentOS 3 EOL, ...
- Development: The state of Linux gaming; Firebird, Ganeti, LLVM, Sawfish, ...
- Announcements: Software Freedom Conservancy appoints Kuhn as full-time executive director; Black Duck acquires Ohloh; articles about WebP, patents, Android, ...