[lang]

Present Perfect

Personal
Projects
Packages
Patches
Presents
Linux

Picture Gallery
Present Perfect

Christmas presents

Filed under: Fluendo — Thomas @ 16:05

2005-12-24
16:05

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.

1 Comment

  1. Free mp3 decoding GStreamer plugin!

    Fluendo has negotiated with Fraunhofer for permission to distribute an mp3 decoding plugin for GStreamer (this will allow Totem, Rhythmbox and all other GStreamer applications to decode mp3) without infringing on his patent. The effort will be open sour

    Trackback by Blog — 2005-12-26 @ 02:14

RSS feed for comments on this post. TrackBack URL

Sorry, the comment form is closed at this time.

picture