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
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
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
- Languages. Rockbox can operate in Afrikaans, Bulgarian, Czech, Greek,
Hebrew, Swedish, and Wallisertitsch. Oh, yes, it works in English
- 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
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
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
[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)
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
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
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
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
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)
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
content protection act of 2006 [PDF]
. The purpose of this law is
To authorize the Federal Communications Commission to limit the
unauthorized copying and indiscriminate redistribution of digital
audio and video broadcast content over digital networks.
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:
(b) permit customary historic use of broadcast content by consumers
to the extent such use is consistent with applicable law;
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:
(b) "Secure Moving Technology" is a technology that permits content
covered by the Broadcast Flag to be transferred from a broadcast
receiver to another device for rendering in accordance with
customary historic use of broadcast content by consumers to the
extent such use is consistent with applicable law and that prevents
redistribution of copyrighted content over digital networks.
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
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)
Page editor: Jonathan Corbet
Next page: Security>>