LWN.net Weekly Edition for January 26, 2006

The Grumpy Editor plays with Rockbox

Last May, your editor lamented that, while his new digital audio player had a number of nice features, it also had a long list of glitches which, due to the proprietary nature of its firmware, could not be fixed. At that time, a Rockbox port for this device (an iRiver H340) was still a distant prospect. Since then, the situation has changed somewhat. In particular, on November 24, 2005, Rockbox hacker Linus Nielsen Feltzing announced his ability to play music on the H300 series. This nice little player had, at last, been cracked open and put to work running free software.

Your editor took his time before giving Rockbox a try. There is something intimidating about rewriting the firmware of one's expensive electronic toy with untried new code covered in "this is experimental, only to be used by professionals and idiots" warnings. Maybe it has to do with the prospect of turning said toy into an inert paperweight and having to explain to the spouse that it will be necessary to buy yet another gadget, urgently, to replace it. But, eventually, after a suitable amount of loin girding, your editor launched into the process of generating a new firmware blob and loading it into the player. Happily, said player did not explode.

The Rockbox iRiver port works by applying a patch to the standard iRiver firmware. That patch adds a special bootloader, and a few other Rockbox-specific things. Unlike the native system, most of Rockbox lives outside of the firmware; it is, instead, loaded from the internal disk. Among other things, this organization makes it easy to upgrade the Rockbox code without going through the sweaty-palms firmware flashing experience every time.

The bootloader normally just grabs the Rockbox kernel from the disk and runs it. Quite a bit of effort has been put into making the bootloader robust, however. If the on-disk software cannot be found, it simply boots into the iRiver firmware. There is a power-on key sequence which can be used to get the iRiver code. The bootloader is also programmed to drop into the USB mode if the disk's filesystem is corrupted, giving the user a chance to fix things - though, since the H3xx bootloader's USB mode does not work properly yet, that feature is not as reassuring as one would hope.

One might well wonder: why bother changing operating software and risking turning the player into a brick when it worked reasonably nicely before? Here are a few of the things that Rockbox brings:

• Boot time. The iRiver firmware takes 26 seconds to boot on your editor's player - and that is with the "database" feature, which lengthens boot time, disabled. Rockbox is ready to play in ten seconds. When one is, for example, trying to play some music before driving, the difference is significant.

• Gapless playback. Your editor's music collection includes many works which, to put it mildly, do not benefit from the one-second gap that the iRiver software puts between every pair of tracks. Rockbox does not have that problem.

• Bookmarks. Some audio files (like the interesting set of Long Now seminars) can be over two hours long. Imagine listening to the first hour of such a file, then picking up one's children to haul them to the next in their long list of activities. Said children will, of course, immediately grab the player and put on a Beatles song (one must raise them on the classics, after all). With the iRiver firmware, returning to the previous file involves painfully fast-forwarding in until one finds a spot near where one left off. Rockbox, instead, can automatically place a nice bookmark at the spot where listening stopped, and jump right back on request.

• Codecs. The iRiver already played Ogg files (a big part of why your editor chose it in the first place). Rockbox adds other formats, including AAC, FLAC, Shorten, and more.

• Configurable screens. The iRiver firmware, when playing, wastes much of its gorgeous color screen space with useless frobs. Rockbox allows the "while playing" screen to be configured with great flexibility, with the result that it offers a wide variety of information-dense screens - in ugly monochrome. Color patches are in circulation, happily, but they have not made it into the Rockbox mainline yet.

  

• Plugins. There is a long list of plugins available for the Rockbox software, many of which make nice use of the color display. Most of them appear to be games (like "Brickmania," shown on the right). Yes, you can now solve Suduko puzzles on the iRiver. But there is also a calculator, a clock, a playlist searcher, a metronome, and more. A color video player is in the works.

• Audio menus. Rockbox can, when loaded with a suitable voice file, read out menus and track names as they are selected on the display. The Rockbox mailing list has a steady stream of inquiries from blind users who are not well served by commercially available audio players.

• Languages. Rockbox can operate in Afrikaans, Bulgarian, Czech, Greek, Hebrew, Swedish, and Wallisertitsch. Oh, yes, it works in English too.

• Playlist generation. The iRiver software cannot generate playlists at all (they must be loaded from a computer), and, annoyingly, it can't do basic things like "treat this directory of files as a playlist and stop when you get to the end." It is easy to leave the device running by mistake, only to find (usually at the beginning of a long trip) that it has drained its battery trying to play one's entire music collection. Rockbox has a number of playlist generation options, and is generally better behaved in this regard.

The list could go on for a while, but one should not forget the nicest part of all: Rockbox is free software. Your editor did not feel particularly oppressed by the proprietary iRiver firmware, but switching to a free system still brought a sense of relief. So many things were clearly designed with the users in mind, and one knows that the rough edges (of which there are still many) can be fixed. With Rockbox, this gadget has become a living thing, rather than a set-in-stone consumer product. Rockbox would be worth running for its free nature alone, even if it weren't better in so many other regards.

There is some bad news: the iRiver H3xx players are no longer being made, and iRiver's replacements are rather more closed devices. There is no Rockbox port envisioned for current iRiver players, so people are now wandering around on online auction sites in search of the few H3xx players which are still available. The good news is that Rockbox is being ported to a number of other platforms, notably the current set of iPod players. The iPod port page states: "Rockbox boots and appears to be stable on the iPod Color/Photo, the Nano and the Video. Plugins and codecs work, but there is no audio output yet." So, other than one little problem, everything looks great.

As Rockbox becomes more portable, its user base is growing. Rockbox seems to have recently crossed one of those invisible lines where it becomes essentially unstoppable. There will likely come a time when some manufacturers of digital audio and video players - especially those who don't make iPods - will have to seriously consider shipping Rockbox on their gadgets. After all, why should they spend time and money creating their own software, when Rockbox is both free and better? Free software, it seems, has a good chance of taking over another category of systems.

[For those H3xx owners who find standard Rockbox to be insufficiently bleeding-edge: the Rockbox H300 Optimized release is a fork with improved color support, more plugins, remote control support, a lyrics viewer, and more.]

Comments (14 posted)

Suits and Patents: A Report from the GPLv3 Launch Conference

As you approached MIT room 10-250 on Monday, January 16th, you could see the rise in prominence of the GNU General Public License simply by the presence of the "suits". Oh, some had certainly "dressed down" with the black T-shirt/turtleneck and jacket motif instead of a tie, but they were very clearly of the corporate world and a quick glance at name tags proved that: Intel, IBM, HP, Novell were all there of course, but also companies such as Hasbro and many others.

To be sure, the free and open source community was well represented: Bruce Perens, Andrew Tridgell, Chris DiBona, Seth Schoen, and many other free/open source stalwarts. But you would expect them to be here, while the corporate presence was definitely a sign of the times. Indeed, as I sat waiting for the presentation to start, two corporate folks were walking up the stairs behind me and one said to the other "Oh, yeah, we are all here to watch the ground shake."

The ground may not have shaken immediately, but the session began around 10am with Richard Stallman welcoming the crowd of 200+ attendees and providing a broad introduction to the GPLv3. He spoke on the overall goal of increasing the compatibility of the GPL with other appropriate licenses (such as the MIT X11 and BSD licenses) and then discussed the threats of digital restrictions management (DRM) and how it can never be compatible with the goals of free software. At the end, he introduced Eben Moglen, who proceeded to take the crowd through about an hour-and-a-half of line-by-line analysis of this first draft of GPLv3.

In all my years working with free and open source software, I'd actually never heard Eben Moglen speak and it turned out to be quite an enjoyable time. With occasional wit and humor, he guided us through the new clauses and the rationale behind the changes. As others have already provided some analysis and the FSF's GPLv3 rationale document gives their view on the changes, I'll not repeat much of that. His main thrust, though, was that the changes were about the increased compatibility of which RMS spoke, as well as clarifying a number of areas in which GLPv2 was unclear or vague. There was also a good amount of effort put into trying to make the GPL more "global" in the sense that it would better comply with copyright laws of more countries. One example is the new use of the term "propagate" in Section 0 as "distribute" turned out to have some formal connotations in some countries.

Moglen spent a good bit of time on the minimal "patent retaliation" clause now found in Section 2 and the reasons (explained in the rationale document) why the FSF did not go further. There was also an involved discussion of the ability to add additional permissions and requirements and how those flow on to recipients during the propagation/distribution process. Predictably, he spent a significant amount of time on Section 7, "License Compatibility", discussing what the different clauses mean with regard to the other free and open source licenses.

One of the discussions I found most interesting concerned the changes to section 8 ("Termination") specifically around the "60 day" clause. GPLv2 provided for the "automatic termination" of the license if you violated it and the license also essentially required someone in violation to contact all copyright holders to obtain forgiveness for having violated the license. As the FSF was very often the one acting to aggregate the claims and help entities come into compliance, they did see the pain this requirement caused when the process of contacting all copyright holders became long and protracted. In their view, this new arrangement provides a stronger incentive for entities in violation to come into compliance quickly as it gives them some assurance that if they do comply, they will not have the threat of GPL-infringement lawsuits looming over them once the first 60 days have gone by.

Another interesting addition was section 18 that speaks of the program not being tested for use in "safety critical systems". He said that at the time the GPL was first being applied, no one was thinking that free software might be used to run nuclear power plants or other systems that might have critical implications if there was a failure. This phrase was added to explicitly state that programs were not tested for these environments. However, he also said that he fully expects some companies to offer warranties (for a fee) to provide coverage for using such programs in those environments.

Throughout the talk he threw in entertaining quips such as "Most of us would see the copyright law of 1897 as being better than that of 2004", "Protecting freedom is hard work!" and "That's our legal theory and we're sticking to it." He also received a great deal of laughter when he relayed that the warranty sections (now 16 and 17) were not changed at all - except that he moved them from being all in uppercase. He said that he had yet to find a lawyer who could explain why they were all putting warranty provisions in all caps and that it seemed to be something people were just doing because everyone else was. So he decided for the sake of readability to make the change.

Moglen concluded his presentation with a moving comment on the "spirit" of the license and the overall need to preserve "the spirit of tinkering, of hacking, of making an unexpected invention out of the materials lying around". He spoke of this revision process as trying to keep the GPL safe, make it bigger and add more people to the discussion - and with that he invited people to become part of the process. He turned the floor back to RMS who said a very few final words and then opened it up for questions.

Predictably, the questions came quite quickly and were mostly about... patents. Two clauses received the most questions. The first was the "patent retaliation" clause in Section 2 and the second was the part of Section 11 which says that, if you distribute a work "knowingly relying on a patent license, you must act to shield downstream users against the possible patent infringement claims from which your license protects you." The response on this latter part from Eben Moglen was that they are not looking to require companies to search all their patents to ensure they are not infringing before distributing work, but more to prevent people from distributing work that they know requires a patent license which they may already have, but which the people who receive their work will not. He went on to say that this clause really only applies to a very small number of people and companies and that he looked forward to working with them to make sure this clause works well.

Beyond the patent questions, there were questions about the 60-day notice, the DRM provision and some general questions about the process of moving from GPLv2 to GPLv3. Overall it was a very useful, interesting and intense morning session.

My one critique of the FSF conference would be what happened next. As we broke for lunch, a subset of the participants (including many of the corporate folks and high-profile members of the free/open source community) apparently went off to separate "discussion groups" to which they were specifically invited. That left the rest of us (myself included) returning from lunch around 1:30pm to face a "Q&A session" with FSF Executive Director Peter Brown, FSF web/wiki coordinator John Sullivan and a young FSF staffer/volunteer who did not identify himself. After a brief statement around the process that would be starting how to comment online, the floor was opened for questions... many of which could simply not be answered.

I don't really fault the three of them. They tried as best they could to answer some of the questions, but they were definitely out of their element. The questioners wanted to ask specific points about the license and clearly needed RMS and Eben Moglen to be there. After a bit, Peter Brown tried to direct the questions away from the license draft and toward the process, asking for other questions to be held until Eben Moglen could return around 3 or 3:30pm. The frustration was visible in a number of the folks there.

I do understand that the FSF was trying to make use of the fact that it had all of these various folks in one physical location and certainly a room of 200 people is not a great way to get a large quantity of feedback. Small groups work far better for that type of thing. I also know that numerous media personnel were there and that RMS and Eben Moglen needed to spend some time with those folks. Still, given that the published agenda said that the afternoon session was for "Q&A" with no mention that RMS and Moglen would not be there, it was a bit frustrating to learn that it was not the type of Q&A that most attendees wanted.

Having said all that, there were some very good questions raised during this afternoon session. Patents were raised again several times, but a question was also asked about the definition of "Complete Corresponding Source Code" in Section 1 where it includes "any encryption or authorization codes necessary to install and/or execute the source code". The specific concern was about whether code could be encrypted with GnuPG for sending, but I failed to understand the issue as to my mind you would be encrypting it with the recipient's key, so they would already have it.

Far more of a concern for a few questioners, though, was the requirement in Section 6b that you will make available your source code on a "durable physical medium customarily used for software interchange." The concern was that solo developers might have to get into the business of stamping out CDs to distribute source code. It was pointed out by someone there that, per Section 6d, one easier way to comply was simply to offer a download. Still the concern persisted. Interestingly, Eben Moglen stated in his earlier presentation that this phrasing had been inserted primarily so that an entity could not "give you the source code" by giving you a printout, which he indicated was a possible way to comply in GPLv2. Now, you must be able to receive the source code in a fashion where you can use it electronically.

All in all, and even with my critique, it was well worth spending the day at MIT and I certainly think the FSF is to be commended for starting this revision process in such an open manner. While I was unable to attend the second day of the conference, I am sure that it was quite involved, as this is, for all of us, only the start of a conversation that will last most of a year. The GPL is incredibly important in this day and age and all of us should definitely monitor this first revision in 15 years, and get involved as much as we are able. The suits will be there - will you?

Comments (29 posted)

Ugly legislation in the U.S.

While the European software patent debate starts to warm up yet again, legislators on the other side of the Atlantic (where software patents are nothing new) are working at restricting freedom in different ways. In particular, this week saw the return of the broadcast flag, in the form of the digital content protection act of 2006 [PDF]. The purpose of this law is stated as:

Remember that, in the last episode in the broadcast flag epic, a federal court had concluded that the FCC, created to regulate access to the airwaves, had no authority to control the behavior of receivers. So the current proposal aims to "fix" that problem by making the FCC's authority explicit. Under this law, the FCC would be empowered to regulate digital TV receivers, and its previous broadcast flag rulemaking would be explicitly ratified. A separate section gives the FCC authority to regulate "digital audio receiving devices" as well.

Just in case the FCC might change its mind, the bill also contains language requiring that broadcast flags in particular be used "to protect digital audio content." This technology must also:

As others have pointed out, this is an interesting bit of language. Broadcast flag technology is not required to respect fair use or to protect any other rights "consumers" have under copyright law. Instead, it must protect "customary historic use." Given the fuss the entertainment industry has been raising for so many years, it is tempting to say that "customary historic use" includes widespread recording, copying, and redistribution of content. But that is not what the forces behind this bill have in mind, of course.

What they do have in mind is a world where nothing new can be done. If it's not "customary historic use," it can be prohibited. Not that long ago, recording television programs to watch them at a more convenient time was not customary - nobody had VCRs yet. It would not be surprising to see an argument that putting music on a digital audio player is not "customary historic use." Certainly putting one's music onto the hard drive of one's Linux system in order to create podcasts or other interesting derived works is not "customary historic use."

The broadcast flag already rules out the use of Linux systems to do anything with digital content; free software, being free, cannot meet the "robustness requirements" specified in the broadcast flag regulations. But, even if that hurdle could be overcome, the "customary historic use" provision will make it impossible to do anything new and interesting, on Linux or on any other system. It is an attempt to freeze time and give the industry a veto power over any new ideas that come along.

Also to be found in this bill is a requirement for "secure moving technology," defined as:

In other words, the FCC's new authority would go beyond receivers to any other device to which an receiver might be connected. The FCC will be authorized - and expected - to require DRM for any device which might touch digital content. And such DRM need only allow "customary historic use."

The EFF is encouraging letters to Congress in opposition to this bill.

An older proposal, meanwhile, is the "analog hole" bill [PDF]. This law would require video devices with analog outputs to incorporate the CGMS-A DRM and VEIL watermarking schemes. With the combination of the two technologies, the industry hopes to prevent "consumers" (that's us) from doing anything interesting with any analog signals we might be able to coax out of our shiny new, DRM-equipped entertainment boxes.

Ed Felten recently decided to look at VEIL to get a sense for what is truly being mandated. As it turns out, he was not able to. In order to have a look at the VEIL specifications, he would be required to sign a non-disclosure agreement, and pay $10,000 as well. And that only for the decoding side of the specification. So the "analog hole" law mandates the use of secret technology; there will be no opportunity to debate the merits (or lack thereof) of this technology during the lawmaking process. All this leads Mr. Felten to wonder: do the members of Congress behind this bill (or even their staff members) have any idea what they are legislating?

It is bad enough that this law would make it impossible, for example, to put together a MythTV box. But the imposition of secret technologies is undemocratic at best. In this case, too, members of Congress would benefit from well-written input from the people they are said to represent.

Comments (15 posted)