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.
It's scary to see such strife within the Open Source community. I'd much prefer, as would we all, a focus on our true enemies, those who persist in making and publishing proprietary and other non-Free software.
The beauty of it is that we have the option of choosing our battles. Mplayer is a great program, and has made many contributions to the community and innovations to media applications in general (QuickTime, for example). Why go after them? Instead, we should be going after the real offenders, the companies that violate the GPL to line their own profit margins.
Do not forget that mplayer is a powerful tool in our battle against those who would destroy us.
Boromir, son of Faramir, King of Gondor and Minas Tirith
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"
Oh, for crying out loud, GPL isn't a higher law given by some divine force that's gonna strike us down.
GPL is just a convenient wording of several conditions for published program. All the conditions are binding for the user, not the author.
We've been over this several times and it was stated that author can specify any additional conditions, even contradicting the GPL. This was the case for GPL-incompatible BSD advertising clause. It's enough to add permission to link the GPL code against such restricted code.
Nobody, not even RMS himself can prevent me from publishing my software with GPL license and additional condition that this guy that kicked my ass in fifth grade cannot use this code.
Robert
Bastard Operator From 193.219.28.162
The GPL doesn't restrict what you can do with a piece of GPL code once you have it (to do otherwise would be a violation of the GPL). It only kicks in once you start distributing something with GPL code in it.
Similarly, the GPL can't prevent someone from distributing their own source code, even though it would (if compiled and linked with GPL code) not be legal to distribute.
In other words, if one feels that there may be GPL problems with their code, source-only distribution seems to be the appropriated thing to do.
Telling people not to distribute binaries is simply a warning to prevent them from violating the GPL themselves.
Not blatently sensible, and IANAL, but it seems to be legal.
OS Software is like love: The best way to make it grow is to give it away.
I know beyond the shadow of a doubt that we still occasionally find bits of non-free software that have slipped into the archive. Debian's resources for checking licenses are limited, and not every Debian developer has the same eye for license problems.
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
Then you chose the wrong license. GPL does not bar anyone from "taking [your] program, modifying it, and selling it for a profit." The only restriction is that they must provide the source, if requested, and retain the original license. Redhat, Mandrake, Suse, and every other Linux distribution that you can purchase, do exactly this.
When I release GPL code, I don't care who does what with it so long as it remains available to everyone. The money is secondary. The code that I release on a subscription model is not GPL for obvious reasons. That money pays my bills. Not every project needs the GPL; use it where it makes sense.
-Hope
I'd say you are the one being childish. What do you think happens inside of Microsoft or IBM legal? The difference here is that everything is public. Frankly the Debian legal team seems to be pretty liberal as lawyers go, in real life lawyers will often say that they could easily win the suit but...
--correct me if my understanding is incorrect, regardings the major distro vendors and GPL code. They sell cd media, printed dead trees manuals and custom support options, but the code itsef is not sold, it's freely given away. Now they could charge a reasonable fee, if they chose to, for downloading as well, but that's a delivery/bandwith/infrastructure fee for still *free* code.
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
If this were possible, you could for instance, charge for the right to download binaries.
You could charge for the bandwidth. Just like Sun claimed that you can order a free Solaris CD on x86 from their website.
Follow me
1. Distribute the rpm or deb as a tar archive that installs in /tmp
/tmp/mplayer-src;
./configure --prefix=/usr /tmp ./mplayer-src
2. make sure the rpm or deb depends on all the nifty things you want to include, as well as gcc.
3. post-install:
#!/bin/sh
cd
make
make install
cd
rm -rf
So long, and thanks for all the Phish
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.
#!/bin/bash /tmp/mplayer
/ mplayer"
e .net:/cvsroot/ffmpeg"
/tmp/mplayer
# Begin
export CFLAGS="-O2 -w -pipe -march=athlon-xp -mcpu=athlon-xp"
export CVSROOT=":pserver:anonymous@mplayerhq.hu:/cvsroot
cvs -z3 checkout main
export CVSROOT=":pserver:anonymous@cvs.ffmpeg.sourceforg
cvs -z3 checkout ffmpeg
rm -rf main/libavcodec
mv ffmpeg/libavcodec main
rm -rf ffmpeg
cd main
./configure --prefix=/usr \
--enable-new-conf \
--enable-menu \
--with-reallibdir=/usr/lib/rp9
make && make install
exit 0
# End
bash-2.05b$
This kind of ranting, raving, finger-pointing, and concept that rules should be made with the intention to be used as clubs is the _exact_ reason I quit frequenting #debian. This has also played a role in my migration of almost all my boxes to Gentoo. Software runs faster, the atmosphere in #gentoo and on the mailing lists is much more amicable, and I think they have a better distribution concept.
... after all, it gets compiled when you emerge mplayer.
Of course, mplayer works quite well with gentoo
RFC2119
Why did you compile all the GNOME shit inside it ? It's not required and would remove 2/3 of the libs shown by you.
"when in fact it was their own code that was not up to the level of C compliance that the compiler required."
heh? non-compliant code may cause compiler internal errors? miscompiled code? it should cause compiler warnings/errors. otherwise it IS compiler's fault.
A'rpi/MPlayer team
But not all of the code in MPlayer is based on other peoples gpl code, much of it is written by the mplayer team themselves... and any binary distribution of mplayer would require this code in order to function, so surely theyre well within their rights to request that people dont distribute binaries of THEIR code... I doubt they would complain if you built object files of the gpl`d code they reused from other projects, ofcourse on their own you wouldn`t have a very usefull program...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Apple don't permit you to hack into the Sorensen codecs and get them to work outside Quicktime Player.
Who needs Apple's permissions? Where I live it is explicitly permitted by law, and the law even says that right cannot be given up by agreement.
Do you care about the security of your wireless mouse?
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."
You will notice the ".hu" at the end of their URL. That tends to mean that US laws don't apply to them.
Well, besides their jurisdiction problem, there is also the matter of lawyer's fees. Take a look at the history of software patents... Unisys didn't give a damn about LZW until they noticed that there was critical mass, and people wouldn't be able to completely stop using LZW even if they wanted to. The same goes for the MP3 patents. They don't give a damn until there are large pockets from which they can pick.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
After reading a good portion of the posts of that thread, I'd say debian should just not include an MPlayer package for the following reason: They fear they could be sued for including a package with questionable legality and their only idea how to solve this problem is to remove everything they think might set of someone. Stuff like libavcodec.
However, this would cripple the program beyond useless and probably make Debian users think it was totally uncapable a program. I say, if you can't include a player like this in it's full glory, don't. Maybe they could provide some information to the user where to get MPlayer? But throwing it in the same toilet they threw Xine in (ie, leaving out everything that might make it useful), that can't be the answer...
If a train station is a place where a train stops, what's a workstation?