Last February, the Participatory Culture Foundation announced
with the launch of the "Democracy" player, billed as "the
world's first comprehensive open source Internet TV system." Many Linux
users may be excused for not trying out the program at that time; despite
being a GPL-licensed program, Democracy had not been ported to the Linux
That situation has now changed; on September 11, Democracy 0.9
was announced. It runs on Linux, and packages for Debian, Fedora Core,
Gentoo, and Ubuntu are provided; the source is available for everybody
else. Beyond the Linux port, this version promises a polished user
interface, a new playlist capability, Flash video support, and more.
Your editor clearly had no choice; a tool like this simply must be tried
Unfortunately, the Democracy experience is still rather spotty at best. It
requires the installation of a number of proprietary codecs (which is not
particularly surprising, once one thinks about it - the Democracy
developers will have no magic solutions there). The system can be sluggish
to respond, and your editor never was able to get it to display a video in
its own window. It also would not explain why it failed to display
anything, so there was little to be done about it.
But your editor was able to get far enough to realize one important thing:
video display is not really what Democracy is about in the first place.
This tool is really a sort of video feed aggregator for free video content;
it has all the required features for sorting feeds into categories,
collecting votes for interesting videos, using BitTorrent to download
videos in a provider-friendly way, and more. There is also significant support
for people who want to create their own video feeds.
What Democracy and its supporting foundation are trying to do is to get as
many people as possible into the business of creating and distributing
interesting content. The term "Internet TV" is somewhat off the mark -
Democracy will suit couch potatoes just fine, but its real purpose is to
get them off their couches and participating in the process. It is trying
to create a world where video content is free, universal, and compelling - so it
has tools for finding and distributing videos but a distinct lack of DRM support.
This is an important goal - television is too important to leave to the TV
companies. If the Democracy system can help to bring more free content
into existence, it will have done a good thing. Some progress in that
direction has been made: there are, it is said, some
600 channels of free content available now, and, doubtless, more to come.
The current code has real promise; it looks like a capable system for
discovering, distributing, and managing interesting video content. If they
can get past
the remaining troublesome issues, the Democracy hackers will have created
a valuable tool indeed.
Comments (13 posted)
One month ago, LWN ran an article
about the cdrtools license change
and resulting controversy. The
biggest issue remains the distribution of binary versions of the
utility. This tool is licensed under the GPL, and has
copyrights held by a number of authors. The current version, however,
requires the libscg library - which is now distributed under Sun's CDDL
license. Since the GPL and the CDDL are mutually incompatible, it is hard
to see how mkisofs can be distributed legally.
That situation has not changed in the last month; cdrtools author Jörg
Schilling appears to be determined to go forward with the license change.
What has happened, however, is that a number of distributors have responded
to the change - though not all have responded in the same way. Here is a
summary of what the distributors are doing:
- Debian was the first distributor to notice the license problem,
and the Debian developers have reacted quickly. It now appears that
etch will ship with cdrkit, a new project based
on a version of cdrtools from before the license change. The Debian
maintainers are actively pushing forward with this project, and they
have approached other distributors to see if they want to help.
- Fedora has dropped back to the 2.01 release, which predates
the most controversial license changes. That change allows them to
get the Fedora Core 6 release out without excess worry or delay
while the longer-term plan is worked out. That process appears to be
going slowly, with the Fedora cdrtools maintainer not yet
participating in the discussion.
Meanwhile, Fedora has also slipped a version of libburn into the Extras
- Gentoo has taken an interesting approach. Since Gentoo
distributes in source form, the developers have concluded that they
need not worry about this issue. There is no combination of
mkisofs and libscg until the end user builds a binary - and
the user has the right to do that. As long as those binaries are
not distributed, licensing does not come into play. Thus, Gentoo
ships the (relicensed) 2.01.01-a11 release.
That said, the Gentoo developers have also put cdrkit into their distribution, and
it looks like that is what they plan to support going into the future.
- Mandriva has made no public statements about the license change
at all. The recently announced
Mandriva 2007 release candidate contains version 2.01.01-a11, which
includes the relicensed code.
- Slackware has no recent cdrtools-related entries in the current
changelog. The upcoming Slackware 11 release appears to be
poised to ship version 2.01.
- SUSE's response, so far, is
"We'll look into cdrkit." The current "factory" OpenSUSE
tree contains version 2.01.
- Ubuntu currently has 2.01.01-a3 (which predates the license
change) in the repository for the
upcoming "edgy" release; cdrkit has not yet made an appearance there.
It would be surprising if Ubuntu failed to follow Debian's lead on
The overall picture that results is that, while a number of distributors
are taking overt action in response to the cdrtools licensing issues,
others appear to be waiting until things settle - and a final 2.01.01
release is made. Only one of the distributors listed above (Mandriva)
looks set, at the moment, to distribute a version of cdrtools released
under the new license.
For years, there has been occasional talk of forking the cdrtools package.
It has remained talk, however; CD burning can be a tricky task, and, as a
result, cdrtools is not a trivial package to take on. It now appears
likely that this fork will happen at last; the licensing changes
have given the distributors (at least those most concerned with these
issues) little choice. The real remaining question, then, would be: just
how many forks will result? No distributor has an interest in taking on
the full maintenance of a package like this, so the incentives should be in
place to bring everybody together on a single CD burning utility.
Comments (4 posted)
One of the often-proclaimed advantages of the free software development
model is that of peer review. Our code, we claim, is better because it has
been reviewed and improved by a variety of people beyond the original
author(s). Reviewers, with their unique perspective, will find bugs and
generally help new code fit properly into an existing project. This review
process is seen as being so important that a number of projects will not
accept code until it has been picked over by other developers.
So reviewers are a fundamental part of the process. They are also, it
seems, somewhat scarce. Consider a couple of examples:
- In the kernel space, the reiser4 filesystem has been held up for some
time. There are many reasons for that delay, but one of those has been the
lack of a thorough review by somebody who understands the Linux
virtual filesystem layer well. Greg Kroah-Hartman, in his OLS
keynote, said, more generally: "The big problem ... is
we really only have
a very small group of people reviewing code in the kernel
- The PostgreSQL developers have been engaged in a lengthy discussion on
the upcoming 8.2 release, why it is taking as long as it is, and why
this release appears (to them) to have little in the way of exciting
new features. The conversation has touched on various aspects of that
project's development process; there are many things for those
developers to think about. One of them, though, as expressed by one of the participants, is:
"...the real problem seems to be we do not have enough patch
If we truly believe that code review is a crucial part of the free software
process (and, for the most part, it is likely that we do believe this),
then the idea that projects are being slowed by the lack of reviewers is a
bit worrying. At best, a reviewer shortage will be a bottleneck in the
process; a worse possibility is that some projects will simply decide to do
Reviewers serve a number of purposes. They can often immediately spot that
bug that the developer has stared at for hours without finding. If the
code is hard to understand, the reviewers will be the first to notice. If the
associated documentation is incorrect or (as is more often the case)
absent, the reviewers will notice that as well. When code appears to have
been written using some sort of specialized, non-public knowledge,
reviewers can inquire as to its provenance. Coding style issues, API
misuse, inefficient algorithms, use of outdated interfaces, and more can be
caught in the review process before the code hits the project's mainline.
Reviewers really do increase a project's code quality and long-term
The problem is that code review can be a difficult, tiring, and thankless
job. Human nature being what it is, people will often show less than the
appropriate amount of gratitude when a reviewer points out their mistakes
in public. This is especially true if the code has problems which will
require significant amounts of work to fix. The reviewer did not create
these problems, he or she is simply the messenger with the bad news. So
reviewers tend to get grumpy, especially when they see the same mistakes
being made over and over again.
Developers get credit for their work, in various forms. It is a rare
project release, however, which publicly acknowledges those who reviewed
the code. Given that writing code is not only a more visible activity, but
it also tends to be more fun than reviewing code written by others, it is
not surprising that many developers choose to concentrate on their own
Finally, reviewing code can be intimidating - especially if the patch of
interest has a Big Name behind it. Many potential reviewers may feel that
they simply do not have the standing to poke at other peoples' work. The
fact is, however, that even people with a relatively small amount of
experience can provide useful reviews, and learn from the process. From
Greg's OLS keynote:
When you are learning to play an instrument, you don't start out
writing full symphonies on your own, you spend years reading other
peoples scores, and learning how things are put together and work
and interact. Only later do you start writing your own music, small
tunes, and then, if you want, working up to bigger pieces. The same
goes for programming. You can learn a lot from reading and
understanding other people's code. Study the things posted, and ask
why things are done specific ways, and point out problems that you
If we want to create the best free systems we can, we must ensure that the
review portion of the process does not get slighted. To that end, people
who have the requisite skills would do well to dedicate a bit of their time
to reviewing code in a project that interests them. Buy a reviewer a beer,
and forgive them if they tell you, in front of hundreds or thousands of
developers, that your work is best suited for a place in the project's "bad
examples" repository. Listen to what the reviewers say, respond to it, and
thank them. The result will be better software for all of us.
Comments (21 posted)
Page editor: Jonathan Corbet
Next page: Security>>