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."
I agree with Debian-legal, and have to say they are being generous by only pointing out the obvious problem with the GPL. The biggest problem with MPlayer (and the one that it's developers can't fix so easily) is that much of the code was appropriated from other projects that lack proper (or in some cases, any) licenses. I'm sure if the MPlayer people were to say that "OK, MPlayer is pure GPL" that the next question will be to what extent they even have the right to do that. It's unfortunate, but because proper attention was not paid during development, MPlayer will probably be a permanently grey-area application legally.
Those are just a few quotes from Gabucino, an MPlayer developer posting to debian-devel...
Um not exactly. The GPL says you can't restrict ANYONE ELSE from distributing.
So you CAN cgharge a fee to download. You can even package it up and sell it on store shelves. You CANNOT stop anyone who gets it from you from doing the same (or giving it away for free).
Now, you may dislike that too, but the specific restriction that you cited (that its not possible to charge for binaries) doesn't exist.
In fact, the original author can chose to distribute under a non-gpl license in addition to the GPL if he likes.
And getting back on topic...this sounds very similar to pine. Debian you will notice doesn't distribute pine because pine doesn't allow binaries built from modified source to be distributed. So debian has no license... so debian obeyed the licence.
the mplayer people ask why "Debian legal" thinks it knows better hwat the GPL means than they do. Its not that at all. Its that debian, as a distributer, at som elevel has to answer the question "Do we have license to distribute what we are distributing" and they are basing that decision solely on the text of the licenses involved. Its that simple.
Debian, by policy, does not violate software licenses. Quite simple. Debian also does not accept special licensing terms (ie "You the debian group may distribute this, but noone else may") as they are. Since debian is doing the distributing, its the debain people (not the authors of the stuff being distributed) that have to make the call as to whether the license gives them permission to distribute since it is debian that puts its neck on the chopping block if it distributes something they have no permission to distribute.
-Steve
(a rather inactive debian developer, who used to read the debian mailing lists and thinks this issue is nothing new)
"I opened my eyes, and everything went dark again"
This is for MPlayer 0.90rc3-3.2.1. Note that this listing doesn't count the 74 Windows
(insert some random less-compressable stuff here to defeat the lameness filter. All this thing does is piss off legitimate users. The crapflooders have all gone home, you can turn off the gzip-nazi filter now, Taco!!)
0 1 - just my two bits
This attempt at working around the GPL by having the user build the app has been tried before, by no less than Steve Jobs. Apple's Objective-C compiler was and is GCC-based, but originally Jobs wanted it to be proprietary. Apple came up with a scheme where the equivalent of a Makefile would take a pristine GCC tarball, plus the proprietary patch, apply it, and build a proprietary Objective-C compiler. However, the FSF lawyer (Eben Moglen) found precedents that he could use to convince Apple's lawyers that this strategy would fail. The reason is this: Apple would build and test the binary in house. They had a mechanism that would cause the bit-for-bit identical binary to appear on the user's disk. They have in effect created a mechanism for distributing a binary, and this binary is a derivative work of GCC. They can't do this without a license from the FSF. The details of the mechanism don't matter. The "mere aggregation" exception doesn't apply because the pieces being distributed are not logically separate.
Now, this gets us into a very controversial area: lots of folks object to this concept, because if taken to an extreme it would appear to prohibit people from telling other people how to do patches. Nevertheless, the Mplayer people should not assume that they have come up with a safe and legal way to mix GPL and non-GPL code. If they provide a Makefile that creates a binary, in a way that the binary the user gets is the same one they have, then they could well be sued by the owners of whatever GPL software they use.
The problem is, it's difficult to make good MPlayer binaries
It's difficult to make good MPlayer binaries because MPlayer is badly written. 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. Instead, it's a sprawling mess with files all over the place and a special codecs.conf acting as a central registry. Why can't each plugin tell Mplayer what capabilities it has, like Xine or XMMS does?
MPlayer is famous simply mostly because it got Win32 codecs to work outside Windows. Kudos to them for doing so, but distributing other people's binary codecs is usually illegal. Apple don't permit you to hack into the Sorensen codecs and get them to work outside Quicktime Player.
How would the like MPlayer authors like mplayer to be embedded as a binary in some media player, without source? Oh yeah, they whined like kiddies when that happened.
I happen to write decompressors for various archive formats. Do I just take DOS binaries for those formats and hack into them to run them in Linux, then say "x86 only guys!"? No, I fully reverse-engineer the originals and write new depackers from scratch. The MPlayer team should do the same, and stop relying on other people's binaries for their glory.
Does my bum look big in this?
I never said MPlayer was perfect code. It isn't, but making a perfectly modular approach while supporting so many different formats and codecs is easier said than done. I have to agree the condecs.conf is kludgy.
Reverse-engineering is the perfect solution, but in practice it can only be done for simple things. Reverse-engineering WMV or Sorensen v3: you can't be serious, this is almost impossible unless you're either a authistic genius or somebody with inside information about how the codecs work. In the real world, those codecs will most likely NEVER be reverse engineered. And i don't think begging Microsoft and Apple/Sorensen for Linux versions will work either (laugh!). So what do you do ?
MPlayer is the only project that provides a solution. I couldn't care less how they do it.
DZM
This does not at all reflect the views of the MPlayer authors.
He didn't say that the MPlayer authors don't care about licensing. He didn't say Debian doesn't care about licensing (in fact, Debian seems to insist on strict adherence to the GPL more than just about any company out there). He didn't say that most *companies* don't care about licensing issues.
He said that most PEOPLE don't care about licenses. And, I believe that holds true.
How many MP3s do you have for which you have no corresponding CD in your posession? How about ROMS for video games? Windows installations (even if you own one, do you run it on more than one computers)? How about 30-day shareware with no hard timeout, which "expired" about two years ago?
People care abour convenience and functionality. If they didn't, how many people would *BUY* Debian or RedHat CDs? I can download all of that from the net, totally legally. I can download all of the documentation (or at least comparable) as well. Why would I pay for a CD? Because $20 for a 4-8 CD set saves me several days time downloading and burning the same material. OTOH, saving $80-$160 by borrowing a friend's Windows install CD and spending 20 minutes looking on-line for a valid CD key seems very much worth it. Same for MS Office.
People pay for convenience, not because they give a damn about whether or not they legally *need* to pay. I think most people *prefer* to stay legal, given the choice with no extra cost (in time *or* money), but they won't go very far out of their way to make sure they stay legal.
Note that I don't mean this to *encourage* piracy - Just describing how I see this issue WRT other peoples' buying/stealing habits.
Now, to address the parent thread, I have an interesting question...
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...
Talk is cheap. Show us the code.
The devil is in the details. In other words, it is easy to say something is easy until you have done it.
If you have reversed-engineered a significant audio or video codec, I will retract my position and be suitably impressed.
And, yes, I do see you code at http://www.kyz.uklinux.net/packers.php3, but there isn't an audio nor video codec to be seen. It all looks like LZW variants; lossy compression (DCTs, wavelets, and what not) is a completely different kettle of fish.
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
I must admit that I haven't followed the flame in real time on debian-devel (it's archived though). I would just want to point out that:
1. Christian offers a real and useful service to the debian users. Not all of them compile their kernel and software from source.
2. Next to mplayer, he also packages some other software (e.g. lame) which have been removed from debian, but which are ubiquitious. I hope that in term ogg will be a viable alternative, but 'it is getting there', not yet.
3. I've worked with Christian on some 'problem' packages (dependency on mp3lame). I've never had any problems communicating with him and he was always eager to help. He has always answered in a polite way to my questions and offered help AND rearranged his packages to meet my package needs.
4. As a result of my personal experiences AND following the mplayer site and developers a bit, I can only assume their attitude in mails. I wonder if they ever heard of the term _polite_ questions or remark. You should sometimes read the remarks and replys debian devolopers get from some upstream authors.
Fact of the matter is that, unless I have a terrible character judgment, one should be very careful in pointing fingers to Christian, he was packaging video/audio {de|en}coding software before any other distribution heard of these and was and still is offering a real service to the debian community.
Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant."