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
Honestly. I've been an mPlayer user for ages. In the past, the mPlayer people did not like for you to distribute binaries because it was difficult, if not impossible, to build binaries that would perform well on most x86 arcitectures. (So the story goes...) and they tried it (redhat, I think, was first) and got tons of flames and support requests on the mailing list beacuse the binary packages were flaky. It is part their code, lack of a good install script, and some other stuff, but they had a valid point. Especially when you link to external windows libraries and things like that-- it seemd to get real flaky if you had precompiled binaries (at least on redhat) though I'm told some crafty package maintaners have got it down-pat pretty good now. In the early days the mplayer authors didn't want to get a rep that their software was bad or flaky. The software was great... yeah the installer could have used some work, but...
So befoe you flame them about a GPL, try to understand their (at least historical) reasons for asking this.
You know, like how they handled UW PINE.
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.
From reading the flamewar that is the news thread, I got this much:
1) They use GPL & code under another license that isn't GPL compatible, plus their own code.
2) They never distributed a binary.
3) The released all that code.
4) Their code had an added clause that states you can't distribute binaries.
So the problem was, they used gpl & gpl incompatible code, so the resulting binary could not have been legal under any license. So they just simply didn't release a binary. I don't see a problem here. It's not against licenses to distribute GPL code next to gpl-incompatible code... it's just illegal to compile them together and distribute.
Just build mplayer statically - should solve dep problems (it would use more memory, but not significantly I would think).
My Debian machines will still have mplayer on it regardless of what Debian decides to include in their distro, but the fact remains that what goes into a Debian distro is entirely up to the Debian folks. Poking at them on the list isn't going to (and shouldn't) change that... Sure, but this messy flamewar might make some people in debian's legal team have another look at mplayer and the patent issue(what this is all about, not the binary distribution...), and start a useful discussion, which has already started at the time i write this, btw. The beginning of a real disussion is imho about there: http://lists.debian.org/debian-legal/2003/debian-l egal-200301/msg00153.html
So what do we have now? A gory stupid flamewar that was the ignition to something which might end in the inclusion of mplayer in debian.
Of course it might as well just not get included, but who knows?
-- we're dressed in green, and we're feeling mean
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
mplayer has actually an gui, and it is pretty themable/skinnable (I think much in the way gqmpeg or kjöfol is)
Like many people, I despise the GUI that they've come out with. Tiny buttons, can't read worth a shit, get in the way, really. I have set my wmv/avi/mpeg/divx/whatever mimetypes to invoke mplayer in a shell and use the default keyset to navigate. Sure beats YAPIGUI (Yet Another Poorly-Implemented GUI).
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.
I hat e to break it too you, but this does not signify to "downfall of Debian" it simply points out that you are not a target user of Debian. The whole point of the entire project is a free system. By them makign stands on otherwise useful software and not giving in one can see that the project is running as well as it should. I am not saying I want granny to run Debian and have to search for URLs etc, I'm saying that Debian is a project heavily rooted in the politics, and I for one am happy to see that there still are people who will sacrifice a little "usability" for thier values.
IANADD - (I am not a Debian Developer)
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.
I'd almost welcome a BSA audit - it'd be fun to yell "IN YOUR FACE!!!" every time they get snippety.
I'm not sure BSA audits are legal, BSA is a private company who has no right to even look at my screen, at least in france.
See this article (in french, sorry) for example.
blah
This is what the debian people aren't getting:
Some licenses are incompatible, even if they're all opensource. So what mplayer did was redistribute all the source, but you couldn't compile it together and redistribute it because of the license incompatibilities.
Distributing license-incompatible source together isn't illegal because it's not "linking". License incompatibilities don't come into effect until you link them together.
MPlayer does NOT have a license that says you can't redistribute binaries, but since compiling mplayer would link together incompatible licenses, that binary cannot be distributed without breaking the GPL.
So debian was free to redistribute binaries, as long as they didn't create binaries that linked in incompatible sources.
(This is about older versions of mplayer anyway.. the current versions of mplayer can and do have binaries being distributed)
Mandrake packages who's legal or licencing status is uncertain are not supplied in the distribution.
However, many are available (including mplayer) in Mandrake RPM format via PLF (the embarrassingly-named Penguin Liberation Front).
Instructions are even included for setting that site up as a URPMI repository ('urpmi' being Mandrake's equivalent to 'apt-get' - installation of packages, automatically resolving and installing dependencies). Note however, that some PLF packages require packages from Mandrake contrib repositories.
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
If you can't legally redistribute, then most likely you can't legally compile it either.
This is what you don't seem to understand. The binary result has the same license as the source. If the source licenses are incompatible, the binary is illegal.
But it's okay it the user makes the illegal binary instead of the developers? This is your argument?
This is my sig. There are many like it but this one is... Oops. Frank, I've got your sig again! Where's mine?
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.
I agree, Debian and OpenBSD seem to be unique in the way that they care about the legality of what they are doing and how it matches their project goals.
They seem to put a high value on their 'customers' never running into legal issues, while other distros seem to care more about what they can get away with.
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.
This is perfectly legal. As long as you purchase 19 other license certificates from Microsoft. It's part of their "Volume Licensing" program. Even so, the CD Key just unlocks the CD. As long as you have unique certificates of authenticity for each box, you're OK.
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?
I used Debian for several years and still use it on the servers I administer. Before then I used a little Red Hat and before then Slackware.
Gentoo is very similar to Debian in the way the packaging system works. You simply tell them what to get and they download and install it and anything else it requires.
Debian distributes binaries which are pre-compiled for your platform. For intel they're compiled against the 386 I believed. Debian is also slow to update due to testing, but that in turn makes it quite stable and reliable.
Gentoo is a bit more of a tinkerers OS. It downloads the source code for any package you want to install and it compiles it custom to your PC. My Gentoo system is compiled specifically for my Athalon XP system.
Also Gentoo tends to update more quickly than Debian, in part because just throwing the sources at your users is easier than packaging up and compiling/testing yourself.
I enjoy using Gentoo on my desktop OS, but I wouldn't use it on a server until it matures a little more. I also wouldn't use it on a slow computer as compiling source code can take awhile. I also wouldn't recommend it to someone who doesn't want to know what's going on under the hood of their desktop.
Gentoo by the way it's setup tends to walk users through the a lot of the core functions that make your OS tick. It doesn't hide your config files in GUIs. Even the installer is very much a hands on process where you manually mount, chroot and fdisk. But at the same time it has very nice documentation for these processes so even non-uber-geeks can work through the OS.
I'm not sure what you mean.
If I write a piece of software, hold the copyright on it, and make it available under the GPL, the GPL gives me no additional rights. I'm not bound by the GPL; as creator and copyright holder, I'm free to charge for the software. I'm free to distribute it under as many licences as I desire. I'm free to relicense it to whomever I choose.
The GPL only covers the rights of third parties who distribute code to which they do not hold copyright. The restriction there is that these third parties must make the code -- or code derived from the code -- available under the same terms as they received it.
Put another way, Red Hat can take my GPLd program and distribute it freely. They can charge for it. They can modify it. If they distribute it to you, either freely or for a fee, they must allow you the same options.
how to invest, a novice's guide
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
Debian does that. It provides a pine396-src package, which contains the source and patchfiles.
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.
We've never said that we invented all of them.
It's enough to look at AUTHORS, it's allw ritten down weel.
Btw, your numbers about xine's qt support are far from reality: xine had only SVQ1 video decoder (they rev.eng'ed). But 90% of teh mov files with SVQ1 has QDMC/WDM2/Qclp audio which has no opensource decoder. So xine actually could play 10% of the SVQ1 files (20% of total movs nowdays).
The rest needed SVQ3 and Q* audio support, we made. Along with the whole RealVideo reverse engineering you forgot to mention.
The Win32 DLLs support (except quicktime) was developed by the avifile project. XMPS just took that code just like we or xine or others.
But note taht we're working togetwer with Zdnek kabelac (avifile maintainer) to improve teh DLL loader and we've added support for many DLLs already.
A'rpi/MPlayer team
ps: we do NOT prohibit binary distribution! otherwise why would we offer RPM binaries for example??? We don't _like_ binary distribution, it's a BIG 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
Audio compression is lossy. DCT, wavelets, and psychoacoustics are PART of AUDIO COMPRESSION!
The message on the other side of this sig is false.
In debian (and perhaps gentoo), it is easy to get mplayer installed,
:)
...
... then ..
:)
.... they pulla me back in!
# acquire
wget ftp://...mplayer-link.../MPlayer-0.90rc3.tar.bz2
# decompress source
tar jxvf MPlayer-0.90rc3.tar.bz2
# acquire useful directory state
cd MPlayer-0.90rc3
# [X] build a debian package
fakeroot dpkg-buildpackage
# fix various complaints about packages missing
# (best to do this in another window; must be root
# or apt-get set{u,g}id root, which is pure evil)
apt-get install fakeroot libpng12-0-dev libgtk1.2-dev
# do [X] again
fakeroot dpkg-buildpackage
#
cd
dpkg -i mplayer_0.90rc3-0_i386.deb
Whammo. You have mplayer. Ok, by "easy" I mean "repeatable sequence of commands", not "point and click", I guess.
Cheers
Brian
- Just when Ih think I'm out
rpmbuild --rebuild --with fullstatic --with plf mplayer-0.90-0.rc3.2mdk.src.rpm
on a reasonable new Mandrake system and you'll get a static binary.
AFAIK MPlayer's GUI doesn't use GTK+2 but GTK+1.2, so it's really useless to link to libglib-2.0.so.0 & Co.