Jamendobox

June 8th, 2007

iconWell I already knew that Jamendo allowed you to download their catalogue in Ogg, but by itself it was just an interesting side-note. (Jamendo being the primary site to get liberally licensed music, often biased towards francophone nymphs)

But to my surprise I tried Fedora 7 Rhythmbox a few minutes ago, expecting nothing much but the pile of Gnomic crud that assaulted me last time I tried it. Ah no, mashed up with Jamendo (but apparently not as planned Magnatune) Rhythmbox has become more than the sum of the parts and has crashed uninvited into iTunes territory.

It has become a native client app you can start up and listen to a big catalogue of liberally licensed music, not only without the expectation of having money sucked from your living veins but even with the expectation of being moved to voluntarily donate to the people sending you their hard work for free, when you especially appreciated what they offered.

And there on the menu bar is the legal, sanctioned, intentional “download album” button. In the face of this must you go and give money to the lawyer loving corporate coke snorting beast-creatures for mainstream crud? Or should you not set out to make a direct connection with the artists and show them your appreciation in a direct and personal way?

An extraordinary advance for standard Linux media players!

The Alignment Monster

May 25th, 2007

insanity at the laptopCurrently I am working on an embedded Linux ISDN-2 device I have designed… the hardware works fine but it’s clear that the challenges lie in the software stack. ISDN uses a cryptic, stateful protocol called LAPD to manage call state and features many layers of protocol stacks to get the job done. You know you are dealing with the old school when they refer to 64kbps log coded PCM as “3.1kHz voice”, meaning the audio bandwidth.

Naturally at this.. mature… stage of ISDN development (ie, I am plundering the ancient dusty tombs of a dead protocol that happens to be in wide use) I am not anxious to become a guru capable of winning arguments at the bar on ISDN protocol trivia, instead I need the freaking thing to work. If it’s a new technology, exploring the byways and understanding it closely can often pay off in the future, but there is much less chance of that when dealing with something old and basically deprecated (cf ADSL). So I chose to use mISDN, an attractive proposition with a driver for the chipset I am using and capable of working in both NT and TE modes — basically allowing acting as the exchange and the customer.

mISDN is getting some reasonable use as part of Asterisk via chan_mISDN, so I hoped for an easy ride. However it is clear that mISDN has not had much of a life outside of x86. The Makefile is not set up for crosscompile and indeed the thing from git when I started on it would not compile against a current kernel source. In fact the thing caused a segfault in the kernel build process on contemporary kernels, the two-line fix for which represents my first contribution to the actual Linux kernel tree. (Rather a weird bug… the text CONFIG_MODULE appearing in any source file will cause the build to fail with a segfault in a script. This text appeared accidentally in mISDN — CONFIG_MODULES was meant which did not trigger the bug)

Read the rest of this entry »

Bonsai code-kittens

March 31st, 2007

80 column limitThe last few months I have been working on the Penumbra project. I started off patching wireless drivers in and out of the kernel tree to achieve the anonymous broadcast action that the project needs, but it became clear this would be completely unworkable for general use… getting wireless up in Linux can still be a struggle and hoping people will patch their driver or kernel in addition isn’t going to happen. After trying a couple of other methods in the end I created a radiotap-based packet injection patch for the mac80211 stack (formerly dscape / d80211), and bound it together with a patch from Michael Wu that provides radiotap-based Monitor mode. At the moment it is still in front of the linux-wireless folks and it’s not clear what the result will be. If the patch is accepted, then the code should make it into the mainline kernel and all mac80211-based wireless drivers will work with Penumbra out of the box in the future. The patchset provides generic radiotap monitoring injection that “just works” with libpcap both ways, so I am hoping it will get accepted without people having to form an opinion about Penumbra.

But one of the biggest hurdles in creating the patch was not technical, since I already had the core functionality working, but in fact the Linux kernel coding style. In some ways the coding style fits well with my own personal style (formed over 20 years of writing C and C++), we basically use the same K&R style. There are some spacing and commenting rules that are actually better than my style and I will adopt them wholesale. But that’s where the fun stops and the recrimination begins!

Read the rest of this entry »

Nasty Crash at Luton Airport

March 4th, 2007

Plasma display at Luton Airport shows Windows BSOD

Makes no sense to have a license to Mordor for each of the hundreds of plasma displays at Luton Airport. It sparked a conversation with my stepson about why it was chosen: presumably because the devs didn’t know anything else than Windows, they will spend the rest of their working life acting as agents for Microsoft. This is the fruit of the Jesuit priest Ballmer’s creed of “give me a developer until he has 7 months in the industry and I will give you a Microsoft Trained Monkey”.

Using the same or cheaper hardware, an embedded Linux implementation would have had at least the same performance and much more flexibility. Ogg Matroska is a patent-free high quality video solution that plays back out of the box on Fedora for example. And if you wanted a hundred or a thousand displays your software licensing costs would stay at exactly $0.

Out of your tree

March 3rd, 2007

Out of your treeThe willingness of the kernel devs to refactor stuff is both a huge strength and weakness for the kernel. The strength is in the extraordinary continual optimization and improvement in the codebase, not just locally to an area of code but for cross-kernel concepts, like the recent workqueue changes.

But this has a pretty harsh cost for people writing or maintaining code that is outside the kernel tree and which therefore does not get the reworking applied to it as part of the core kernel. Whatever code they put out is invalidated and broken again and again sometimes in just the space of a few weeks.

The freedom to refactor despite breaking external code is a huge luxury for the devs seldom seen elsewhere in the coding world. Some projects take some care to allow compilation of their drivers for all recent kernels, using conditional compilation based on the kernel tree it is being compiled against, but other projects have an attitude that it will only compile against the current Linus tree.

The foaming churn of change makes for pretty hard work trying to make any kernel code that is not in the main tree work for any length of time. Greg KH at least is on record that his concept of the solution is to bring everything inside the kernel tree, but I don’t know how that will ever scale, and it loads the devs with having to understand a work with an ever growing amount of device-specific code. Aside from that, it makes the kernel devs gatekeepers for what will be accepted, and since not everything that can exist will be deemed acceptable, there will always be a class of device driver that is living out of the comforts of the main tree.

Anyway the end result is that for many projects that people need drivers for, the shelf-life of any instance of the driver sources is extremely narrowly defined. A Wifi driver for example touches many subsections of the kernel that have a history of changes in the recent past, yet requires a pretty recent kernel to compile at all with the stuff that it actually needs. So each driver tree has a quite narrow slot of kernel versions that it will work with, annoyingly current CVS from many drivers will not compile against current kernel source, not -git either but -rc versions. It means that out of tree drivers are a lottery for any recent kernel any kind of driver is a high commitment project, that needs constant revisiting to keep it alive.

There doesn’t seem to be an answer except that over time more and more critical subsystems in the kernel will surely mature to the point that they get fiddled with less and less, and things should therefore die down on the breakage front. But in truth the adolescent codebase of Linux shows no signs at the moment of slowing down its crazed foaming froth of reinvention and massive damage and breakage to the code around it.

Octotux Packaged Linux Distro

January 27th, 2007

For the last couple of years I have been working with the AT91RM9200 ARM9 chip from Atmel. This is a very nice, fast, cheap CPU when combined with some SDRAM and NOR flash. One of the bigger problems I faced getting started with it was managing the sheer amount of sources that go into a modern Linux implementation. Many embedded folk just generate a giant tarball which is their whole root filesystem, they don’t track what versions are where and as a result providing sources for their magic tarballs can be a pain in the ass for them.

I knew I didn’t want to repeat this method from the start, so I began to work towards being able to use the RPM packaging system even with my crosscompiled stuff. Having the full RPM app and database doesn’t make sense for an Embedded system though, for example our standard AT91RM9200 platform only has 8MB of flash for all nonvolatile storage. I found that the excellent busybox had the start of an rpm implementation already, but although the code was really well-written, the implementation was not complete enough to do anything useful: it did not keep a database and there was therefore no possibility to erase packages, for example.

Over a few months I added more functionality to the busybox applet, including keeping a “database” of installed RPM headers down /var/lib to emulate most of the capabilities of real RPM. With this in place, I then went on to package all of the apps that I was interested to run on my distro. There are numerous advantages to formalizing the management of code into packages once you accept that you will only place packaged stuff on the device.

Creating an RPM binary also creates a source RPM (SRPM) that is contains all of the sources and build specification for that binary, and both the binary and source are versioned. Therefore so long as you offer the matching SRPM at the same time as you give someone the binary RPM, your GPL requirements for giving sources are solved in one stroke.

The patchlevel of any device can now be interrogated and used to select updates as well, in a formal manner. You can also express the need in a package to have “required” dependent packages of specific versions, reflecting a common situation where after some release you need a library of a certain version for it to work.

The “cost” for this level of control over your device boil down to: no more ad-hoc building. Even development builds are done through rpm packages. We provide a script that will remotely install over scp and ssh the latest version of a given package from the host commandline, even one that rebuilds the package before installing it remotely, and for every single edit you can be certain the sources are captured in the SRPM. We found a typical system is using only 100K of uncompressed data (typ 50K on jffs2) to maintain the RPM headers that make the packaging work. That is not significant even on a box with only 8MBytes of Flash.

Check out the Wiki at http://octotux.org for more details and the repository which contains the packages.

Your code might be Free, but what about your data?

October 3rd, 2006

Two Three Letter Names of FOSS bring their ships around for a Vision Collision

RMS (Richard Stallman) just had an interview with the fairly major investment magazine Red Herring. A lot of the content isn’t new from him, but as usual some of it is spot on.

Q: Do you think you will ever achieve that goal?
A: I don’t know because it depends on you. That’s why I resist these self-fulfilling prophecies. If enough of us demand freedom we’re sure to win and if few of us demand freedom we will almost surely lose. It’s entirely up to the readers of this article. As so many issues are to the extent that we still have democracy; so if people were told by businesses they want this and you know you can’t [oppose] businesses so just get used to it, go along, suffer. If people lie down and take it then they will lose. So what do [businesses] do? They are smart: they encourage people to lie down and take it.

[This happens on] many issues and not just this one. Pick any political issue in which things get worse and you’ll find people telling the public: ‘It’s inevitable. Don’t try and fight it; it’s useless. of course, if we did bother trying to fight it, we might win.

A couple of items down on LWN where I found the link, there is another story, about ESR (Eric Raymond) joining the “Leadership Team” of Freespire, and it is the juxtaposition of the two stories that is the real story.

Although the Press Release says people were surprised “in recent weeks” about ESR’s speaking out about the need to work with proprietary data formats, his interest in the issue goes back as far as March 2006. He was on fedora-devel then making the same suggestions with the same urgency, basically that although Linux was doing quite well, it was really let down by the lack of support for proprietary codecs. There followed a discussion about why there was no MP3 support out of the box in Fedora; the patent situation appeared to be news to him. He was basically campaigning for Redhat to start defying patentholders and ship mplayer and other such contraband to allow the most complete possible proprietary data format out of the box. It was explained to him that if we as generally pretty penniless individuals decide to download and use mplayer, that is one thing; if a cash-rich American corporation like Redhat decide to start distributing some of the mplayer stuff, which is fairly clearly containing copyright and patent infringements in the US at least, it would strongly motivate the rightsholders to mount an attack to separate the proposed Redhat-idiot from his pile of cash. Redhat are lawyered up enough to be completely alive to the danger, even with regards to MP3. After several days of back and forth, with Alan Cox weighing in quite negatively towards ESR, he moved on to greener, well, less Red, pastures.

So as it happened it was my good self that perhaps brought linspire’s more commercial attitude towards Linux media player apps to the attention of ESR. To underline a point I will be developing in a moment, I sent him a link to linspire’s legally patent-licensed DVD player app several months ago. (Michael Robertson, Linspire honcho, earned some serious gratitude from my family and I for funding, via a prize after the fact, the original Xbox Linux hacking work that I got a fair chunk of, in fact that kept us afloat for about a year).

Now one of the things I realized during that thread, which is the point of this post, is that the conspiracy between copyright law enabling the licensing of works how the rightsholder sees fit (consistant with compulsories that exist in the case of music) and patent law enabling the holder of the patent rights to control the ability of people to play back content that can only be decoded according to their patent, gives proprietary software like Windows a niche that it can’t be winkled out of by FOSS equivalents.

If content rightsholders insist on patented codecs for their content, well, that defines their content as needing licensed playback devices, and that in turn (exceptions like the recent weirdo-licensed free MP3 license for FOSS aside) insists that there is paid-for player doing duty, which violates the share and share-alike basis of pure FOSS. If content rightsholders insist on end-to-end TPM-backed crypto lockups in addition, well that requires a proprietary hardware system with a proprietary OS.

Therefore proprietary software is validated and given meaning by the rights conferred by Copyright and Patent laws. It’s given a future by the deeply embedded and accepted laws that underpin expressions of creativity in developed countries. FOSS can’t equally compete without violating laws that have been proven many times to have vicious teeth: this is an area where FOSS can’t do what it is doing in the areas that are not so wrapped up with globally enforcable rights.

And now we come back around to the elements at the start of this post. RMS knew this long before I worked it out in the middle of an argument with ESR. RMS does not have a lot of time for the traditional media channels

Q: What is the solution to making the free software movement successful?
A: People should boycott all digitally restricted media and if you can’t get your computer to copy it then you shouldn’t buy it. If you don’t have free software to read a DVD you shouldn’t get a DVD. We are calling a boycott on things like HD-DVD and Blu-ray. The solution is to eliminate DRM. There is no situation in which DRM is excusable. Maybe you will be able to access peer-to-peer networks to these songs and movies; I hope so. At least that won’t put chains on you, so it’s ethically legitimate.

Q: So, you don’t watch any movies on DVDs?
A: I have a few DVDs that are not encrypted and I don’t have anything that would play an encrypted DVD. Hollywood sets out to make crap and most people who see it already know that it’s crap before they go to watch it. It’s not quite the same as boycotting all movies. Boycott all movies that you don’t have a reason to feel that they’re good. And it’s obviously different from the simple boycott but the practical result is the same.

Q: Which movies, according to you, are “good” movies that you have watched?
A: My memory isn’t very good but I have seen movies that I feel like are not crap. I like Spike Lee movies and I also liked Galaxy Quest—it’s a comedy which makes fun of Star Wars and its fans, and turns into science fiction. It’s rather fun. I also like Spartacus.

Q: Which was the last movie you saw?
A: The last movie I saw was Spike Lee’s Inside Man and I saw it on an airplane to India, which is where I end up watching most movies.

Well he goes too far with “There is no situation in which DRM is excusable.” in fact I demand some kind of DRM on my bank account, you can call it privacy or encryption but it is in fact Digital Rights/Restriction Management. As he correctly points out in his nomenclature, success against DRM depends on the generic consumer rejecting it. In my philosophical terms, the evil is coming out of the DRM consumer. Without the gormless willingness of the consumer to accept the restrictions inherent in what they chose to give money for, an evil action of the rightsholder cannot bear fruit. But where my own data is being kept from me for a larger reason — so I cannot manipulate my own bank balance by hacking it — this is in a larger interest shared by everyone.

But still: RMS understands what ESR rejects, it is not enough that the code is Free, the data, the content has to be Free too. mplayer, bittorrented mainstream content, they are free but they are not truly Free, and they cannot be with the laws as they are. It is a shift as big as FOSS vs proprietary to move to a world where the data that you consume has the same Free rights as the code used to render it. How can the philosophical shift from proprietary to FOSS be played out on the content? jamendo.com shows the way but how can the content take advantage of the same aggregation advantages that code can?

Rights and Wrongs of Hacking Source Licenses at Distribution Time

September 21st, 2006

The highly interesting busybox license change process rumbles on. For me at least, it is the first time that I saw anyone really try to grapple with the implications of the upcoming GPL version 3 on projects that licensed some or all of their sources under GPL V2 “or later” terms.

As I described in my previous post, until now nobody seems to have thought through the ramifications of allowing a distributor to specify the license version he chooses to distribute under, or how he should specify what he has done in a non-conflicting way.

There must be a surefire way to use and distribute a GPL 2 “or later” package under GPL 2 rules. For example, so that a recipient cannot try to apply the GPL 3 “give me your crypto keys” rules when the distributor honestly and correctly wants to play only under GPL2 rules. But as I described in the previous post, merely noting that you distribute the sources under specifically GPL2 rules leaves the package you pass on in conflict with itself. The source files in the package are still annotated to allow “modification” under the terms of the GPL 2 “or later”.

What I proposed on the busybox list here and explained more clearly here was that a very strong way to make it clear how you are distributing would be to modify the GPL terms shown in the source files, ie, to show that you are distributing under GPL2 only as allowed to by the license, removing the “or later” part from the originally GPL2 “or later” sources. This has the advantage that the distribution method is consistently shown throughout the sources, and the action is ‘sticky’, ie, if you were given those sources under GPL2 only then they remain GPL2 only through further distribution.

While the maintainer seemed to like the idea, there was a cognet objection from Glenn L McGrath, who says

GPLv2 clause 9 states "If the Program specifies a version number of
this License which applies to it and "any later version", you have the
option of following the terms and conditions either of that version or
of any later version published by the Free Software Foundation."

I dont see where it implies the right of licensees to remove the "or
later" statement. For all i know removing the "or later" clause may be
adding a further restriction to the license which isnt allowed according
to clause 6.

In addition to that concern, Clause 1 of GPL2 also seems to not like the idea as I noted in a reply

''1.  You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty;  keep intact all the
notices that refer to this License  and to the absence of any
warranty; and give any other recipients of the Program a copy of this
License along with the Program.''

Well something will have to give. What is needed is some definitive recipe to tell people who wish to distribute GPL2 “or later” projects under specifically GPL2 terms, as the license grants them the right to do so, such that unfair – unfair because they in good faith chose to play under GPL2 rules – GPL3 demands cannot be applied to such distributors.

Bruce Perens and the current busybox maintainer ended their argument for now by agreeing to both consult with the Software Freedom Law Center, a place that has found its moment to leap forward with advice I should think. So hopefully instead of IANAL there will shortly be an opinion from someone who IAL and who has a grasp of the confusing niceities of the text for a change.

GPL2 “or later” distributor sends mixed signals when distributing as GPL2

September 19th, 2006

A couple of people have pointed out something that is important about the GPL2 “or later” license: the distributor chooses the license version they distribute under. (Actually the busybox maintainer Rob Landley pointed it out last week too). The actual language used on sources licensed as GPL2 “or later” looks like this:

* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.

Note that this text uses “you” and “your” to apply equally to everyone who gets distributed to and who is distributing.

In the “distributor chooses” reading of this text:

* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.

a new class of information is generated about the distribution action which I did not see expressed anywhere so far, that is a sort of distribution action license versioning metadata. For example if Nokia have a GPL 2 “or later” package on a secure (crypto-locked) phone platform, in the “distributor chooses license version” reading when distributing they can specify “Nokia gives you this specifically under the GPL2, so no keys”. If the guy then distributes the package on, he can choose the terms afresh, but since he has no keys for the Nokia platform that has no impact on Nokia.

The distributor cannot make a GPL V2 “or later” distribution action stick when he gives it out under, say, GPL V3. If he says, here, have this GPL V2 “or later” package under GPL V3 only terms, the recipient need only redistribute it to himself or through a friend to have it validly on GPL V2 terms again. So it seems this distribution action license choice is only useful for one thing, getting the distributor out of distribution conditions found in later license versions, it seems it can’t be used as a forced upgrade off older license versions.

Simply by stressing ‘modify’ rather than ‘distribute’ from the and/or:

* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.

the text can equally be read another very different way, which is that the distributed-to person is granted the right to modify the sources “under the terms of” the GPL version he chooses. Someone who makes this reading of the text can believe they had a right to apply for example GPL v3 duties on their distributor, and ask them for the keys needed to allow installation as specified by the current GPL3 draft[1]. Folks can argue the distributor saying (where? when subsequently challenged?) that he distributed on the terms of GPL v2 beats out this reading, but it’s not that clear to me because it was also the distributor himself that gave the recipient the license telling him he had the right to modify and distribute according to the terms in GPL V2 “or later”; if modification and installation according to GPL V3 needs the distributor’s keys the GPL V3 gives a way to demand it of the distributor. There are at the least mixed signals coming from the distributor in this case it seems to me.

These proposed considerations only apply to GPL V2 “or later” licenses, stuff like Linux which is GPL2-only seem to have no risk that GPL V3 provisions might be claimed as duties for the distributor.

[1] http://gplv3.fsf.org/gpl-draft-2006-07-27.html

”1. Source Code … The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code…”

I’ll make you free if I have to lock you up!

September 18th, 2006

Interesting goings-on over on the Busybox list. Busybox is a single app that masquerades as a large set of common unix tools like ls, a shell and so on. The maintainer is planning to, well, sort of migrate the project to being GPL v2-only. It’s a bit complex because there are a variety of copyright notices floating around in there at the moment. He discussed it on the list for some time and although there are some people that want to have GPL2+ (meaning, GPL v2 or any later version at the user’s discretion) the proposal seemed to be gaining traction.

The issue is significant, because in the current GPL3 drafts there is language that would require any signing keys to be given up with the sources. If you plan to design a device which, for the security of the customer, would reject code, eg, updates, that were not signed by the manufacturer, then the GPL3 would appear to disallow using GPL2+ or GPL3-only licensed code with such a scheme.

Linus has already come out against this idea as one of the reasons he will be sticking with GPL v2 for Linux. But of course Linux is just one part of the puzzle, and Linux is fairly unusual in having changed the default language of the GPL v2 license from “version 2 or later” to fix it firmly with v2 only. There is a lot of code out there that may suddenly inherit this “I demand your crypto keys because I am treating your code as licensed under GPL v3″ problem simply because they left the default “v2 or later” in there.

Bruce Perens, who was in at the start of Busybox but left it many years ago, argued on the busybox mailing list against changing the license to GPL v2-only, but I think he is mistaken. I think GPL v2 “or later” licenses may turn out to be a very ugly can of worms. In any event the result was the maintainer a few hours later announced that busybox was going v2-only.

The problems over on busybox are the first sign for me of what may be a major licensing train crash brought on by the thoughtless handing over of the author’s licensing terms to Richard Stallman. Great man that he is, that is a lot of power he is channelling right now, he alone, through the FSF, can randomly dictate the licensing terms of a vast body of “GPL v2 or later” code that is currently in use. Under the banner of “increasing freedom”, he is in the position to disallow current usage of existing code that is currently used in accordance with the license. For an unlikely but illuminating example, if he decides that the GPL v4 requires the distributor to donate $10 to the FSF, then recipients who decide they will use “GPL v2 or later” code on the GPL v4 terms can force the distributor to do this. And this is on code that is currently used based on the fairly well understood GPL2 terms where there is nothing like that.

Now you may scoff at such a wild straw man argument, but I discover over the weekend there are people that believe that the GPL v2 requires you to give up any signing keys you may use on a binary created from it! In a subthread starting here, Rich Felker proposes the idea as fact and I argue against it. Later in the thread Rich insists he will take people to court if they fail to deliver such keys; I bring up Redhat’s own signing of GPL’d packages as a case where he should attack according to his principle. He deflects this by saying that since it is possible to install unsigned packages, he will not need to sue Redhat. However, yum by default will not install unsigned packages, and besides you cannot do so without the root password for the box. For many reasons, a user may not have the root password. Does Rich propose that everyone with a box with GPL v2 software on it must be given root access? There has been no reply.

Anyway, it is all getting a bit chilling this talk of negating the possibility of actions of users of free software in order to make them free. It’s starting to sound a little bit like the start of a tortured logic found in Socialist states, where the workers must build palaces “to be free”, grub around in the fields to feed people in offices “to be free”. Purely by that innocent sounding “or later” found in the default GPL2, a huge amount of power, proportional to the amount of software with “or later” in the license, has landed on one person, Richard Stallman. Was everyone really aware they had elected a Great Leader, no matter how trustworthy, and that their package was part of a mobilization force under orders from above?