Present Perfect

Last year we gave away our Cortado Java applet. This year, it's a legal zero-cost mp3 decoder plug-in. You can download it from our new webshop.

What does this mean in practice ? (I am not a lawyer. Check with your army of lawyers. For all we know I may be making shit up).

For end users, they can download our binaries from the shop, and use them to legally play back mp3 files on Linux. Our agreement with Fraunhofer allows this - our patent license we negotiated applies to the product defined as "Fluendo mp3 GStreamer plug-in". Currently, we have i386 and x86_64 Linux builds, and ppc and other platforms will probably follow as soon as one of us gets round to it. If you have an Intel-compatible CPU, we also provide a binary that is built with Intel's optimisation library, which also makes it really fast.

For developers, our source code is available under the MIT. You are free to tinker with it and change it. Normally it is legal for you to run a binary built with your modifications - as long as you are not distributing the binaries you build. The patent license from Fluendo only applies to the binaries we built for you; but it seems Fraunhofer considers building binaries for personal use or research purposes fine.

If you want to get your changes distributed, you simply send us patches, we incorporate it in the source tree, and we build new binaries for the next release. Make no mistake - this is an open source project. Every piece of MIT code out there does not necessarily grant you the right to distribute binaries freely. It is the responsability of the user to make sure he is allowed to run the binary, as far as I can tell.

For distributors, we have a contract available that they can sign with us at zero cost that allows them to also rebuild the source into a binary for which our patent license can be used. Basically, it means that they have the right to build the aforementioned product to which our patent license applies.
Whether distributors want to sign this contract remains to be seen of course - obviously there are strings attached because we need to satisfy our agreement with Fraunhofer. But it does mean that Red Hat Enterprise Linux, Novell Linux Desktop or Linspire could bundle this plug-in with their OS, and we hope some of the Free distributions will consider shipping it as well.

Why are we doing this ? Quite simple. mp3 is a very widespread format, and the fact that Linux could not legally play it out of the box in countries where patents apply is posing a lot of problems for adoption. It is one of the most commonly heard complaints about distros these days. Fluendo still fully supports open formats, and we hope people move to using them. Part of that move is being able to play your legacy formats, where you have no choice over the format. Remember, we are not giving away a free encoder.

Why is this different from before ? Lots of reasons. The current open-source decoders for mp3 are all GPL.
Section 7 of the GPL states, among other things: For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

To me this seems like very clear language, though others (most notably, debian-legal) disagree. To me it reads that if I live in a country where patents apply, and I am able to download GPL mad source code, which I am not allowed to distribute further (because I lack a patent license), it means that either a) the author of mad is not allowed to distribute his GPL source code at all or b) the author is not allowed to distribute his source under the GPL at all.

One of the ways to make money off Free Software and Open Source is to offer your code under a different license for a fee. This is something Fluendo does with Flumotion, and this is also what the mad author does. So it's possible the mad author has chosen the GPL for this reason - it makes sense to do so.

In any case, the MIT license avoids any language about patents. One possible reason for other projects not having chosen this license is because it also does not require you to contribute modifications back. So in some sense, we do incur the risk of people "stealing" the code and modifications we made. But that's fine for us - the advantages outweigh the disadvantages.

The practical difference may not matter to you as an end user. You may be living in a country where patents do not apply, have gotten a copy of the mad source code, and be running a plug-in linked against it, and it's not your concern whether it was legal for someone else to distribute this. Or, you think that the patents that are claimed to apply to mp3 are not valid, and thus you do not need to have a patent license. Or, you ignore patents altogether, and just install a plugin to play mp3, no matter which it is. So you could say, big deal, why should I care ?

Maybe you shouldn't. It's just that as far as we can tell, this is the first time you can install mp3 decoding on your Linux box, legally everywhere - without question - yet still see the source code to it and contribute to the community around it. We think this is as good as it can get within the limits of our agreement with Fraunhofer. If you care about the legality, or you are forced to care because you deal with installations for companies, schools or govermnents, this makes all the difference.

There's been some interesting discussion as a result of this, and I still haven't figured out what I want to see happen in the end. For example, in the case of Fedora, I am not sure I actually want this plug-in shipped by default. I think in the end I would prefer a distro like Fedora to openly and actively support open formats, and make the choice to not ship this mp3 plug-in on principle. Before, the reason was that there was no legal way to do so. I am happy that our plug-in gives distributions something to consider, and might bring each of them to clarify their point of view.

So, are there any drawbacks. Yes. To make a long discussion short (and you should reread the LGPL and GPL if you care about this, and possibly GStreamer's licensing advisory), our understanding is that a distributor cannot distribute the combination of:

1. the LGPL GStreamer framework
2. a binary plug-in that is not GPL-compatible in license (such as ours)
3. a GPL application linked against GStreamer

because at runtime, the first becomes GPL, all three run in the same memory space, and the GPL does not allow linking to GPL-incompatible code. (Remember - the GPL is a license that covers distribution, imposing some restrictions based on what could happen at runtime) Shipping any two out of these three is fine, as a distributor. Running all three together is fine as well, as a user - if at least one of these three was distributed to you through someone else than the original distributor. (Is your brain hurting yet ?)

Applications can choose to add a simple exception clause (or possibly, it's even a "this is how I interpret the GPL" clause, I'm not sure) to their GPL license, allowing for proprietary GStreamer plug-ins to be used with their application. Totem has done this. Sound-juicer is going to add this, I've been told. We've discussed it with RhythmBox developers as well at some point, though I don't know if that got decided upon.

Personally, I think every application writer should decide on this for themselves - and if they make an informed decision to not allow proprietary plug-ins, I think that's a brave decision to make and I support them, because it sends a clear message. People should realize what their choice of license means.

The other drawback is that our code is probably not yet of the same end quality as mad's. The mad author invested a lot of time and resources into his decoding quality. This plug-in was written by Jan based on the reference code, and massaged into a nice typical GStreamer project, gotten some optimization done in the DCT and other places, and received some hooks into Intel's IPP libraries for speed. But there's still lots left to do, and we hope to build a community around it. Most notably, we hope someone takes on the challenge of using liboil to speed up the reference implementation.

if you see this man thank him for legal free mp3 decoding then inform the authorities he was last spotted in Brugge, Belgium

In any case, I look forward to what will happen, and I hope it can make a difference. In the end what it boils down to is that we are offering you more possibilities: the possibility of legally playing back mp3 content, the possibility to distribute mp3 playback capability legally, the possibility to hack on an open-source project and legally use the result of your contributions.

Merry Christmas to you all from Fluendo.

Last year we gave away our Cortado Java applet. This year, it's a legal zero-cost mp3 decoder plug-in. You can download it from our new webshop. What does this mean...

Our dishwasher is one we bought in Gent back when
four guys were living in a big house. We got it from a couple who had had it for a year, and when the house in Gent blew up, Kristien and I offered the dishwasher a ride to sunny Barcelona, which it gladly accepted.

Now, our dishwasher had the peculiar ability to leave streaks of residue on glasses in very specific locations. Over the years I've slowly uncovered more and more potential hiding places for dirt. Each time, after uncovering a new hideout, I was sure to have found every little nook and cranny, and from now on, all our glasses would end up clean. Invariably, I'd be disappointed again after a week or so when my desire to believe they were clean was overruled by reality.

So a few weeks ago, I decided to sit down and look at every square inch of the thing to make sure I wasn't missing anything. I dismantled the whole thing, ran my fingers everywhere and felt inside holes (after unplugging it from the mains, because our flat's electrical wiring is such that we regularly get little shocks from washing machines, dishwashers and computers), until I ran my finger underneath the rubber band all the way at the bottom.

Youch. I've never seen this much black sticky gunk, or smelt this foul a smell, inside any kitchen, ever. It smelt worse than the worst poop I've ever managed to produce, and I went through a whole fresh roll of paper towels before I ended up with a clean one running it under the rubber. This gunk was worse than any of the other gunk I've ever uncovered in any of the nooks inside.

Of course, this time I am again convinced I've found the last hiding place for gunk. Feel free to pop my bubble by giving me hints on where to look next...

And if your dishwasher has a rubber band, now is as good a time as any to go clean gunk from underneath it !

Our dishwasher is one we bought in Gent back when four guys were living in a big house. We got it from a couple who had had it for a...

James, I stopped using drive-mount applet because of this. Granted, there are some more exotic things in there - a few bind mounts, a bunch of nfs mounts that get mounted automatically (for which I have no need for an unmount option, since it will fail anyway), some "conditional" nfs mounts, ...

For me, that was ok - I could do without it. For my dad's computer at home, I was using the old drive mount applet to help him make it easy to unmount floppies after writing to them. It was the only drive mount applet on there. I also had mounts for two nfs shares (used for backup). After upgrading to FC4, the drive mount applet now had a bunch more icons, and it was confusing for him to have two that he couldn't unmount anyway, and the floppy one did not stand out from the others.

Looking at my own screenshot right now, I'm a little confused myself. Some mounts show up as a drive icon, and others as a folder. The difference is probably that drive == not mounted - so that would mean the icons give no indication whatsoever about the type of device/mount they represent.

I agree that it has become very simple to configure, and probably works in the most basic of cases. But even in the basic case, it doesn't seem very usable in its current state. Of course, I am no expert :) I was just too frustrated back when I found this out that I never got round to reporting bugs, because I didn't know where to start. I have very little advice to offer, because I can't come up with an easy solution that doesn't clutter a new preferences dialog.

Maybe some things are detectable from fstab. Some heuristics would be ok - /dev/fd* is probably a floppy, so show a floppy icon. /media/cd* is probably some CD-like device. bind mounts should probably be ignored completely ? NFS mounts for hosts you can't get a ping from should probably not be shown. Distinction between mounted or unmounted should probably be with an emblem, or a color difference (gray vs color ?)

But that's it. The easy way out would be a preference dialog allowing you to pick which to hide. But that would probably make it bigger than the old one was. Thinking about usability is hard...

Anyway, good luck, I hope something comes out of it for the next iteration.

James, I stopped using drive-mount applet because of this. Granted, there are some more exotic things in there - a few bind mounts, a bunch of nfs mounts that get...

Been a while since I mentioned anything interesting about work, so here's a quick rundown.

codecs

[thomas@thomas gstreamer]$ ls
gst-fluendo-ac3dec     gst-fluendo-isofile     gst-fluendo-realdec  releases
gst-fluendo-alsaspdif  gst-fluendo-mp3         gst-fluendo-wmadec
gst-fluendo-asf        gst-fluendo-mpeg2video  gst-fluendo-wmaenc
gst-fluendo-asfmux     gst-fluendo-mpegdemux   gst-fluendo-wmvdec

It'll be nice to get some of these out to a wider audience. If you're interested in being on some form of a beta program for any of this in the near future, let Uraeus know.

JST

Wim has gone back to JST hacking this week. JST is pretty much an implementation of the 0.10 GStreamer design in Java. It's used for the new version of the Cortado applet. It takes a lot less code than the C version.

Interestingly, Wim found a race yesterday in GStreamer because he ran into the equivalent race in JST. The rac in GStreamer never got triggered in practice, but it does get hit in Java because it's a little slower there.

All of this is publically availabe in svn. I haven't tried building it recently, but will probably get back to it when I have some time so we can finally integrate it in Flumotion.

Looper

Edward, our Pitivi hacker, has put together a looper component for Flumotion. Basically, it's an audio/video producer that takes an ogg file and loops it forever. He added a simple UI for it - here's a peek. Looking through his code is a source of ideas for me to finish the flumotion-template and howto on writing components.

RTP

Mike started putting together a Flumotion component for RTP streaming this week based on the code I had written before. It took him less than three days to get the streamer done, with minimal changes to my modules, so that's good. It was exciting to see the stream produced by Edward's looper on the mobile phones. It looks much like in the screenshot above (which has the lowest possible bitrate set for video - hence the quality).

Synchronization

Andy finished his synchronization hacking this week. GStreamer clocks can now be exported over the network, allowing flumotion components to synchronize to one of the other components. Now, it seems, some more fixes are needed in GStreamer elements (for example, correct ALSA timestamping), but the basics are there now.

more to come

Jan is working on something cool as well that I can't say much about right now. But I'm sure some people will be happy with what he's doing. He's almost done and then we can throw something out.

All in all, an exciting week of finalizing bits and pieces at Fluendo HQ...

Been a while since I mentioned anything interesting about work, so here's a quick rundown. codecs [thomas@thomas gstreamer]$ ls gst-fluendo-ac3dec gst-fluendo-isofile gst-fluendo-realdec releases gst-fluendo-alsaspdif gst-fluendo-mp3 gst-fluendo-wmadec gst-fluendo-asf gst-fluendo-mpeg2video gst-fluendo-wmaenc gst-fluendo-asfmux...

There are days where my Spanish is quite acceptable. Last week we had Kevin and Christina over for dinner, and we spoke Spanish all the time. We also went to grab a bite after tango class with some of the other people in class, and we could join in the conversation just fine. Sure, I make a bunch of grammatical mistakes, and I should really spend some time on learning tenses, but overall it was ok.

And then there are days where it just doesn't work out. This week I went to buy batteries, and asked "Tienes baterias triple-A ?" The guy looked at me without flinching and asked "baterias o pilas" ?

At least he had the decency to correct me in this way instead of sending me home with triple-A drum sets.

There are days where my Spanish is quite acceptable. Last week we had Kevin and Christina over for dinner, and we spoke Spanish all the time. We also went to...