LWN.net Weekly Edition for October 7, 2010

Trials, tribulations, and trademarks

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:

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 software non-free:

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:

In fact, according to Adam Williamson, Fedora's policy with regard to Firefox is not driven by the trademark policy anyway:

This claim was not accepted by all members of the Fedora community. Toshio Kuratomi responded:

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)

Rock-a-droid

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 Rockbox. This 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 steps backward.

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

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:

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

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)