Slashdot Mirror
MPlayer Licence Trouble With A Twist
protonman writes "A hefty flame war has broken loose on the debian-devel mailinglist about (amongst other things) the legality of mplayer. The interesting part in this conflict is that unlike in previous alledged GPL violations, the culprit is not the unwillingness to provide the source, but the prohibition of the distribution of binaries, thereby violating section 6 of the GPL: 'You may not impose any further restrictions on the recipients' exercise of the rights granted herein.' Read also the blurb on the MPlayer homepage."
That's why we use "unofficial" debs. Sometimes very scary, such as in Ximian. But, for mplayer this site does well.
Have you read my journal today?
I'm not sure what, exactly, you are saying about MPlayer, considering they link to sites with binaries.
If they had a problem with distributing binaries, why would they link to them?
Sounds VERY fishy to me.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
It seems like this thread explains lots of the issues regarding mplayer and it's inclusion in debian:3 /debian-devel-200301/msg01772.html
:) Just contains :)) :)))))))
:)
:) :))
http://lists.debian.org/debian-devel/200
The message basically outlines this:
xineplug_decode_ff.so 829032 - this is libavcodec, the MPEG4/DivX decoder
Did you pay the royalty to the MPEG Group?
They can come any time...
xineplug_decode_faad.so 164048 - this is the FAAD audio decoder, which is
just as illegal as libavcodec
Vidix - unusable ballast without libdha, which is
not packaged
nvidia_vid.so - part of Vidix.. Instead it is a
placeholder
printf("TODO")
Nice to know xine was packaged by people
who knew what they were doing
xineplug_decode_w32dll.so - code (from Wine) to load win32 DLLs
It's total legal isn't it..?
ASF demuxer - Microsoft already forced a GPL project
to remove it (VirtualDub)
I hope Debian is also ready to face this
xineplug_decode_gsm610.so - xine's gsm610 is GPL, MPlayer's is not?
Nice.
WE say it's GPL.
Its original author says it's GPL.
Debian-legal says we are all wrong??
Make me laugh.
This does not at all reflect the views of the MPlayer authors. They DO care about licensing, and they DO care about being included in distributions.
The problem is, it's difficult to make good MPlayer binaries, and distros tend to leave out the part of MPlayer thay are the most useful (the Sorensen, ffmpeg, windows-DLL based parts), as a result MPlayer authors get a lot of complaints.
The licensing problems aren't really licensing problems. Most of the libraries that are in the gray area are written by people who work closely with the MPlayer team anyway, and/or are designed for other projects and need heavy modifications to be used in MPlayer (one of the conflicts is just based on the absence of a ChangeLog file!!! You gotta be kidding). There's no risk of lawsuit here, it's just some things have not been done 100% by the book. Somehow that's ok for projects like xine (which includes libavcodec), but MPlayer suffers from some bad rep here.
The fact remains: MPlayer is one of the most IMPRESSIVE piece of open-source software engineering i've ever seen, and it's a shame distros a so conservative about it.
DZM
Thats all fine and dandy except when you start including other peoples GPL code which is what the MPlayer people were doing. They were adding restrictions to third party code which they have no right to do.
Let's not forget that your free to choose whatever distro you like. Like I said above, I now use Gentoo for my desktop for a variety of reasons (all source, newer packages, faster due to optimisations, etc) but I use Debian on all my other boxes.
It's an unfair comparison, to put Gentoo and Debian together. Gentoo is like Mandrake (IMHO), it's a desktop distro. It's got great stuff that's pretty new, it's fast, etc.
Debian is, to me, a base distro. It's a rock. NOTHING gets into Debian unless it's been well tested. If you run Stable, you should NEVER have a single crash, it's that stable. The fact is, Debian's unstable branch is equivelent to most other distros out that, in my expirence. If you want a rock solid server, use Debian. If you want to create a great desktop distro, and want a great foundation to build on, use Debian.
Also don't forget that Debian is not just another distro, it's THE distro. Where would free software be without Debian? If you have some odd architecutre, what distro will you run? You can choose some little distro that no one has ever heard of. You could use Linux From Scratch. Or you could use Debian. Debian is on tons of different archs and it's identicle on all of them. Debian is largely responsible for for the porting of, and testing of, XFree on many of the more exotic platforms (IIRC).
Debian may be slow to get new packages, but Debian has a quality that just can't be matched. I may use Gentoo for my desktop system, but I use Debian for everything else. Why? For one thing, whether the machine is a Mac, a PC, or anything else, it looks just the same. I don't have to remember 30 diferent filesystem layouts from 35 diferent distros. I don't have to keep a cheat sheet of how to install packages on that computer (was it "rpm -Uvh", or "emerge", or "cast", or...). Debian may not be as good a desktop distro as Mandrake, Gentoo, Suse, or others. But the fact is that it's the best for just about everything else. Debian is the swiss-army knife of distros. Any platform, any task, anything; Debian can do it. It runs out of the box on 386s or on the newest P4.
In short, Debian is one of the best things to happen to free software, IMHO. Just because it no longer works for you doesn't mean that it now sucks! If I was a corporation deploying Linux on lots of desktops and I wanted something that wouldn't cause me any problems, I'd run Debian.
You can say that think kind of issue is what's keeping Debian off the desktop, and you might be right. You can say that it's the kind of thing that proves that some projects can just get too large to work well as OSS. But it's these kind of issues that make Debian so good. So please don't go saying "Debian will die because of this," when the fact is this is what makes Debian so strong.
And if you don't like the direction that Debian is going in, change it. The elections for the top positions on the Debian project is about to be held. Run for a position.
But I guess it's just easier to whine here on /. than to actually try to influence things the correct way.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Your understanding is incorrect. See Does the GPL allow me to sell copies of the program for money?
how to invest, a novice's guide
The OpenBSD folks do the same thing. It's a nice feeling to have a distro where they're serious about making sure no one else can dictate what can be done with a piece of the system--especially a critical piece. Take ipf, for example. They dumped Darren Reed's ipf in favor of a home-grown pf, all because of some licensing snakiness. And how many of us would figure that out?
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
What you're pasting in your post is not the list of MPlayer problems, it's the list of Xine problems. The Mplayer authors were just trying to prove that there's a double standard here. Xine has as many problems as MPlayer, yet it's included in Debian.
The Debian people, though, have responded that they'll look into those Xine issues and that if they turn out to be true they'll yank Xine out of Debian too.
DZM
Hi all,
/. people. Skimmed the mailinglist a bit and wrote a little something on what I thought was the most "newsworthy" part of the flame war.
/. crowd with a insightful view on OS politics I did nothing but confuse matters more.
/. crowd, but also to the debian and mplayer developers whom this concerns.
:-P
This is the story submitter, and I must appologise for causing this much confusion. I read the blurb on the mplayer homepage and thought it would be interesting for you
As it turns out, the issue is much more complicated than I made it look, and instead of entertaining the
If I were an editor on this website, I would have refused my submission.
I'd like to apologise not only to the
Sorry again,
Protonman.
ps. Licence/License? I don't really care, I'm not a native speaker.
The man of knowledge must be able not only to love his enemies but also to hate his friends.
Using one code to install multiple copies of windows is perfectly legal if you purchase a corporate code from M$. It may not be cost effective with a small amount of workstations but the practice in and of itself is not a legal issue.
...quicker, easier, more seductive the darkside is...but more powerful, it is not.
MPlayer has been referred to as "The Project From Hell" with good reason. This story is just the latest in a long history of less-than-professional behavior from the project's authors. I find it quite humorous that MPlayer's authors accuse everyone under the sun of violating the GPL when their own code is suspect.
MPlayer might play every format, but the software is not particularly intuitive for someone who just wants to play the occasional video clip, the authors see fit to throw public temper tantrums on the project's website, and their support has garnished a lackluster reputation due to the attitude of the authors toward the uninitiated.
The simple answer to the question of why Xine gets more respect from major distributions is that Xine's authors conduct themselves with a far more professional attitude. Remember the MPlayer/Red Hat spat? MPlayer's authors refused to even deal with anyone using Red Hat 7.x because they claimed the compiler that shipped with Red Hat was buggy and problematic, when in fact it was their own code that was not up to the level of C compliance that the compiler required.
You attract more flies with honey. As it is, I don't even bother with MPlayer. Xine, coupled with the gXine frontend, makes a fantastic video player as far as I'm concerned, and it's far more intuitive. I'll take a friendly project over a back-biting one any day.
making a perfectly modular approach while supporting so many different formats and codecs is easier said than done.
But it has been done -- in Xine.
Reverse-engineering is the perfect solution, but in practice it can only be done for simple things.
You clearly don't know how difficult (read: easy) it is to do reverse engineering. It only takes a skilled reverse-engineer (of which there are thousands in this world, most of them are ex-crackers), time and interest.
I've reverse engineered decompression algorithms far more difficult than SVQ3's decoder. Although I haven't seen it, there are rumours that SVQ3 has been reverse-engineered and posted anonymously to Usenet. They say it's just H.263 with some scrambling tables, so Sorensen can claim copyright infringement (of those tables) if anyone writes a decoder. All WMV and WMA codecs have been reverse-engineered. There is nothing mystical or special about a multimedia codec, it's just an algorithm like anything else.
One last example, the even more difficult Microsoft Media Player DRM has been flawlessly reverse-engineered (not by me), despite being actively encrypted and made difficult to run through.
The MPlayer authors are rarely the guys behind reimplementing codecs -- that's what the authors of ffmpeg (libavcodec) do. MPlayer just takes the glory by putting it all together.
Does my bum look big in this?
If the MPlayer license complies with the GPL in all regards *except* allowing binary distribution, that means the authors cannot stop me from modifying and re-releasing it under GPL-or-better terms. So why hasn't Debian done exactly that? "Nope, not MPlayer, we changed int main(int argc, char **argv) to int main(int argc, char *argv[]), much more aesthetically pleasing, and released it as DPlayer under pure GPL terms"?. Seems that the GPL allows that...
:-) (and it's somewhat tricky). I believe the main issues are :
You're right but the issue is no longer the binary distribution (that was fixed long ago). You can distribute MPlayer binaries if you want, except you'll get flamed by MPlayer's authors if you don't package it properly
- MPlayer uses ffmpeg (libavcodec) which some people say has patent issues wrt MPEG4. Xine uses the same library, as it's the only Linux-native DivX decoder (and therefore fastest)
- Mplayer uses modified code from libmpeg2, but didn't include a ChangeLog. No big deal as they work closely with the libmpeg2 project and it'll be resolved in a future version of libmpeg2
That's about it.
DZM
Don't you get that? If the MPlayer authors actually cared about well-written software, it would use carefully crafted, modular APIs between all the component parts. I could add Quicktime codecs to MPlayer just by copying a hypothetical mp_qtime.so into lib/mplayer/codecs.
You don't use Mplayer, do you? To add a codec, simply copy it to the codec directory. End of story. BTW, Mplayer supports all Quicktime codecs.
Apple don't permit you to hack into the Sorensen codecs and get them to work outside Quicktime Player.
Actually, so far, they have. The legal arguments are several.
1) The binary is the same as Windows, and performs the same functions, and is freely downloadable from the provider. Apple. Provided the user does the download, no big deal.
2) The code itself uses a plug-in architecture for Windows and Quicktime dlls, so that copyright issues on different sides of the plug-in interface are separated.
So, Mplayer is GPL, but can still use Windows dlls, when they are available.
The MPlayer team should do the same, and stop relying on other people's binaries for their glory.
They DID reverse engineer SVQ1. And, others are coming, but until they are available, the movies may still be played using the Windows binary codecs, available via plug-in.
Also, the source only re-distribution requirement is now gone, and the binary optimizes for hardware on the fly.
Mplayer is a very impressive piece of software engineering.
If I had installed redhat binaries (cuz I'm lazy like that... and some of my computers are very slow) of mplayer way back when, I would not be using mplayer. At all. Its a kind of rock and hard place situation, really. I can relate to both sides of the issue-- just trying to prevent a GPL jihad from starting. When I went to look for binaries, I found on their website something like "please do not distribute binaries. This is because compilers, libraries, etc vary from system to system and we're doing naughty, naughty things in order for you to be able to execute windows libraries with this code. it is quite beta right now, and we had loads of problems when binary versions of mplayer were popping up here and there. thanks."
It is unfortunate, the wording in their license, but perhaps you should benchmark and profile i386 binaries vs. -O2 -march (whatever)binaries. It really makes a world of difference...
The Mplayer home page doesn't explain the problem - it points you at a flame-war on a mailing list, which has couple of postings about "You suck! No, YOU suck! No, YOU suck and your COMPILER is UGLY! Well, YOUR father smells of Elderberrries and your Hovercraft is full of EELS!", and while it's possible that there's some more enlightening content farther down, there's nothing to suggest that there actually will be, or that this flame war will be any more enjoyable than the last 20 years of Usenet flame wars.
The Mplayer info page says that "MPlayer is GPL now. In the past it contained non-GPL code from the OpenDivX project, which did not allow binary redistribution. This has been removed." It doesn't actually appear to have the license, except perhaps in some hunk of code I'm not going to bother downloading now. If they say it's GPL, then they're obviously referring to the GPL, so I can distribute binaries if I want. If they've got other documentation that's more restrictive than this, well, this one's on their web page, though they probably should have provided a link to the GPL themselves.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Nope, only the work on codecs that have not been successfully reverse-engineered yet. A great deal of the codecs out there are currently handled by libavcodec, from the looks of things.
One suspects a bit of thievery going on here.This one doesn't. :-) The .dll's are only there to enable playback of not-yet-reverse-engineered formats. Given that MPlayer's key goal is "play as many different media types as possible, especially those that otherwise can only be played on Windows Media Player or Apple Quicktime", this seems like a perfectly valid approach until native decoders can be worked out.
And I wouldn't say that MPlayer is "thieving" from ffmpeg (whence libavcodec comes) either. Not only because libavcodec is FOR other projects to use for audio and video encoding and decoding, but because I've noticed that one or more of the MPlayer developers seem to be active participants in libavcodec development as well...
Hacker Public Radio is our Friend