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."

Comments

The simple fact..

[Anonymous Coward]

..is that most people are perfectly content ignoring license issues, as long as the software does what they want it to do.

Most people don't care about licensing. Copying free software, copying closed software, it's all the same.

Re:The simple fact..

[rmadmin]

I'd agree with this. I recently talked to a Radio Station about buying some new workstations from me. They had no complaints about running 20 machines with the same windows key. I strongly urged them not to, but they don't want to pay the fee.

Re:The simple fact..

[DennisZeMenace]

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

Re:The simple fact..

[kyz]

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.

Re:The simple fact..

[rilian4]

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.

Re:The simple fact..

[DennisZeMenace]

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

Re:The simple fact..

[pla]

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...

Re:The simple fact..

[sdowney]

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).

Reading the thread, someone spent about 5 minutes looking at the source for mplayer. He discovered that it included code for other libraries. Those libraries had been modified, with no notice that the source had been changed, nor by who. This conflicts with the letter of the GPL.

Now, the mplayer developers claim that the authors of the the library said it was OK.

So, it it OK for someone else to make changes to the library and distribute it? Is it OK to redistribute the modified version outside of mplayer? What license applies to the modified version? Who holds copyright?

And should you take the word of the mplayer developers that everything is OK?

Would you take the word of the seller's real estate agent that a house is up to code, or do you hire an engineer?

Debian has to asses the risk for themselves. And the mplayer developers aren't being very reassuring about all the i's being dotted and t's being crossed. So it will continue to be the case that mplayer isn't distributed as part of Debian.

Life goes on.

Re:The simple fact..

[Anonymous Coward]

How fucking weird it is that you figure the 'default' state for copyrighted material is to allow copying. Actually, if MPlayer is in violation of the GPL, then they don't have the right to distribute. What's more, nobody but the people who own the copyright on the GPL-ed code has any rights to enforcing that violation. Not you, not the debian packagers, not Dick Stallman, not Jesus, not Crazy Linus, not David Hasselhoff. Nobody. Only the owners of the code with the license that is being violated.

For example, if Martha Stewart was to write up some code and release it under the GPL, and then Pamela Anderson took that code and added to it and released the result with additional restrictions, *you* do not have any rights to that new code. What it means is that Pamela Anderson cannot distribute, it doesn't mean that you magically get the GPL enforced. Even if Martha Stewart decided to sue the fake titted bitch's ass, the only thing she could get would be: 1) actual monetary damages (err, none), 2) punative monetary damages and 3) a court order preventing Pam'sCuntSoftware from distributing the combined project. *You*, personally you, don't get anything out of it. You don't get the code, you don't get money, you don't get a blowjob, you get nothing.

GPL is not some magic form of public domain. People yak about how it's viral (it is) and how it's stupid (it is.) But it cannot forcibly make someone release code that they own the copyright on, regardless of whether it's a derivative. All it can do is prevent them from distributing. God it's fucking amazing how stupid people can be.

Re:The simple fact..

[DennisZeMenace]

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...

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 :-) (and it's somewhat tricky). I believe the main issues are :

- 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

Re:The simple fact..

[blakestah]

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.

Re:The simple fact..

[kasperd]

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.

Obligatory VLC Reference

[philovivero]

Not VNC, VLC. Videolan Client.

It's a way to stream video content from a server and view it on a client, but as a nice side-effect, it's a DVDCSS-enabled DVD player, and a pretty good one at that. It's not skinnable, it uses your built-in OS widgets, so it's not as ugly as all the other media players. It looks like it belongs on your desktop with all your other apps.

Mplayer seems to have much better DivX/MJPEG/blah/blah support than VLC, however, so you can't just go whacking mplayer from your HDD. Sorry.

Re:Obligatory VLC Reference

[tzanger]

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).

That's why we use "unofficial" debs

[Chacham]

That's why we use "unofficial" debs. Sometimes very scary, such as in Ximian. But, for mplayer this site does well.

Re:That's why we use "unofficial" debs

[gibber]

One should note that this is what instigated the whole thread in the first place. Gabucino posted to debian-devel because he couldn't get Christian Marillat to respond to the noted problems with his packages.

Read the thread here

Re:That's why we use "unofficial" debs

[asuffield]

Amusingly enough, the thread in question started because some mplayer developers didn't like Marillat and decided to flame him in public, and people told them to go shove it.

Re:That's why we use "unofficial" debs

[SquadBoy]

But of course as the devs point out you *really* want to compile anyway. They include the Debian rules so it is pretty easy and fast. That is what I and most people I know do.

Re:That's why we use "unofficial" debs

[den_erpel]

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.

There are other legal problems with MPlayer

[Anonymous Coward]

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.

Re: There are other legal problems with MPlayer

[Black Parrot]

> MPlayer will probably be a permanently grey-area application legally.

My concern is where all those .dll's came from. They say that they won't work under Windows, but that just leaves me wondering why they're .dll's to start with, instead of .so's or .a's.

The names of the .dll's suggest that that's where all the codec work is done. One suspects a bit of thievery going on here.

Re: There are other legal problems with MPlayer

[Anonymous Coward]

Those .dll's aren't included with the mplayer source. Mplayer can play avi/xcd/(s)vcd/dvd/ogm/... just fine without em.

Re: There are other legal problems with MPlayer

[Dr.Dubious DDQ]

The names of the .dll's suggest that that's where all the codec work is done.

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...

Re:There are other legal problems with MPlayer

[digital photo]

If that isn't good enough then all I can say is, "come on Debian, be reasonable." Information wants to be free but you're trying set all sorts of childish stipulations on that freedom.

Hmm... well, here's the thing. Debian represents the effort to protect that freedom. I agree that it can be a hinderance in terms of getting things one likes to be included, but when the companies and corporations come down trying to enforce one thing or another, Debian can keep their distro "free as in freedom" because they stuck to their rules and licenses.

I guess one can say that they are being reasonable by being very clear cut about it. This makes it difficult for projects with codes of various backgrounds and licenses, but it makes it so that the whole of their distro is clean(legally) and clean(operationally). It helps to keep the ability of the information in the distro to be free.

The stipulations they set aren't childish in anyway. They are the requirements of their distribution, which is that code/software added to their distro needs to be GPL compabitible.

MPlayer links to sites with binaries...

[shepd]

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.

Re:MPlayer links to sites with binaries...

[HuruRudo]

If I understand it right, the developers weren't distributing the binaries *until* they ironed out all the legal issues with the non-GPL code they included in their tree.

Binary packages are not an issue now, as they claim the code is 100% "GPL compliant".

BTW, mplayer has been included in the latest SuSE Linux.

Re:MPlayer links to sites with binaries...

[jjermann]

Yes, unfortunately :(

It's an unuseable crippled version. The results were unnecessary bugreports of Suse users who couldn't "play DVDs/whatever". At the end most of them compiled it again themself.

Re:MPlayer links to sites with binaries...

[colinleroy]

RTFA, that's not mplayer developers who don't want to distribute binaries, that's debian.

Well, look at their original reasons.

[hklingon]

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.

Re:Well, look at their original reasons.

[hklingon]

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...

You really need to build it....

[hughk]

To be honest, packaging MPlayer as binary is far from easy because it has so many dependancies, especially on some software that is changing. It really is easier to install from source and to run configure and build on your own system to avoid a dependency hell which brings back memories of another well known company.

Once built and optimised for your architecture it does run well, and on my poor little notebook (500MHz PIII), it beats the pants off media player under Win 2K.

Having to build from source is inconvenient, but unless MPlayer is linked statically, I reaaly thing that this is better than installing a prepacked binary.

Re:You really need to build it....

[Isaac-Lew]

Just build mplayer statically - should solve dep problems (it would use more memory, but not significantly I would think).

Re:You really need to build it....

[Cid Highwind]

Erm... let's see here

[will@chi will] $ ldd `which gmplayer`
libpostproc.so.0 => /usr/lib/libpostproc.so.0 (0x40014000)
libdvdnav.so.1 => /usr/lib/libdvdnav.so.1 (0x4001d000)
libdvdread.so.2 => /usr/lib/libdvdread.so.2 (0x40032000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40052000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x400a2000)
libogg.so.0 => /usr/lib/libogg.so.0 (0x400c2000)
libdv.so.2 => /usr/lib/libdv.so.2 (0x400c6000)
libdivxdecore.so.0 => /usr/lib/libdivxdecore.so.0 (0x400f0000)
libpng.so.3 => /usr/lib/libpng.so.3 (0x4013c000)
libz.so.1 => /usr/lib/libz.so.1 (0x40168000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40176000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40197000)
libcdda_interface.so.0 => /usr/lib/libcdda_interface.so.0 (0x401e9000)
libcdda_paranoia.so.0 => /usr/lib/libcdda_paranoia.so.0 (0x401fc000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40205000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x4021a000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x40473000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x404e1000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x404fa000)
libm.so.6 => /lib/libm.so.6 (0x4050f000)
libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x40532000)
libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x40554000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x40561000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x40595000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x405c8000)
libdl.so.2 => /lib/libdl.so.2 (0x405cd000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x405d0000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x4063a000)
libXxf86dga.so.1 => /usr/X11R6/lib/libXxf86dga.so.1 (0x40687000)
libXv.so.1 => /usr/X11R6/lib/libXv.so.1 (0x4068d000)
libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0x40692000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40698000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x406a8000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x40788000)
libvgagl.so.1 => /usr/lib/libvgagl.so.1 (0x407fa000)
libvga.so.1 => /usr/lib/libvga.so.1 (0x40809000)
libgif.so.4 => /usr/lib/libgif.so.4 (0x40876000)
libesd.so.0 => /usr/lib/libesd.so.0 (0x4087f000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x40887000)
libc.so.6 => /lib/libc.so.6 (0x408ab000)
libpopt.so.0 => /usr/lib/libpopt.so.0 (0x409d9000)
libXft.so.2 => /usr/lib/libXft.so.2 (0x409e0000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x409f4000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x409fc000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x40a25000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40eb7000)

This is for MPlayer 0.90rc3-3.2.1. Note that this listing doesn't count the 74 Windows .dlls and directshow filters that MPlayer can also load. You could probably trim off some of that by building it without the GUI, and without some of the more useless video codecs, but it would still require a lot of libraries. Still, I don't even want to *think* about statically linking all of that!

(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!!)

Re:You really need to build it....

[debrain]

In debian (and perhaps gentoo), it is easy to get mplayer installed,

# 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

# ... then
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 .... they pulla me back in!

Re:You really need to build it....

[G�tz]

The Mandrake cooker source package has a switch to enable static linking of the binary. You just need to type this:

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.

Solution:

[dzym]

Provide source for mplayer, such as a tarball .orig and then a patch, in Debian.

You know, like how they handled UW PINE.

Re:GPL is not "free"

[grub]

Avoid the GPL at all costs for your software.

but.. but... "GPL" and "costs" in the same sentence... me is confuzed

Another Great PR Move for the GPL

[glenstar]

Think of different binaries for the possible combinations of MMX, MMX2, SSE, SSE2, 3Dnow, 3Dnow2. and then C code compiled for i386, i586, i686, k6 etc. and then think of non-x86 archs. and then debian can introduce the one-program-one-cd concept.

That is from one of the mesages in the thread.

I would think that any rational person would be able to see the logic in this. However, apparently there are those that cannot. Amazing.

You see... the GPL throws the source at people who don't give a flying fuck about it (in the case of most end-users), and then followers of the GPL get their proverbial panties in a bunch when someone doesn't distribute the *binaries*. I don't get it.

Actually, more honestly, I don't really care. It's things like this that make Free Software zealots look like idiots in the eyes of the public. That is too bad, but until people realize that software is, well, software, and not some political instrument to stake your life on, these things will continue to occur.

Re:GPL is not "free"

[Jason1729]

If I'm a developer writing code that I'm willing to release freely for altruistic reasons, I don't want someone else taking my program, modifying it, and selling it for a profit. That's why I'd put it under the GPL.

You're saying you should have the freedom to profit from my work against my wishes.

Jason
ProfQuotes

We need Debian

[Dave W]

I have made my way through some of the thread.

This discussion again shows to me how valuable the legal team on Debian are. We do not want free software to end up having legal problems due to ignoring licenses. Unfortunately the checking is hard and complicated work so it is fortunate that we can rely on the Debian team.

Just look at the current SCO issues and be grateful for all Debian do to avoid problems like this.

Dave

Re:The downfall of debian

[chromatic]

I'm glad to see a group of people with a consistent ethical code -- especially when those ethics haven't compromised for the sake of pragmatism. (I'm even happier when it's an ethical code that complements mine.)

It seems kind of funny to suggest that Debian needs to compromise its principles to "win the desktop", when the goal of Debian has always been to spread free software, not to "win" anything.

Our solution

[Amsterdam Vallon]

I work in the classroom support field of a major private high school in the US.

We have since stopped using Debian since back at the beginning of the school year (September 2002). Between useless email fights like this one, to other arguments that were show-stopping and delayed new releases, I grew fed up.

I was glad to turn our school's IT system nearly 100% to Linux, but I was almost as glad to switch everything to a package-based, Gentoo Linux flavor.

The OS of Linux is great, but as for the extra flamebait cruft you see on the Debian list, that I can do without.

totally missed point

[DrSkwid]

The aim of Debian might not be to enpower granny to send email but to provide a totally unencumbered OS.

Which is why it seems improper to insult them as "anal" when they are merely following the letter of their mandate.

Would you call Debian "anal" for say, refusing to distribute car tyres with every download? Of course not because car tyres are not what they do. The same is true for free/non-free. Software is either one or the other for some chosen definition and to blur the lines makes no sense.

The main gist....

[catch23]

It seems like this thread explains lots of the issues regarding mplayer and it's inclusion in debian:
http://lists.debian.org/debian-devel/2003 /debian-devel-200301/msg01772.html

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 :) Just contains
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.

Re:The main gist....

[Anonymous Coward]

As I posted on devel-legal about, the inclusion of Xine over MPlayer seemed totally personal.

You, in fact, pasted MPlayer's response as to why Xine should be left out if they leave out MPlayer.

All those files are Xine packages.

Thank you for proving my point.

They are not prohibiting binary distribution now. They did so in the past, but now they are not. The article should have said that the issue was about the FORMER legality of MPlayer, mostly because they broke some licenses earlier on so the could get a shipping player. I would have agreed with Debian then, but now that it is 100% GPL and allows binary distribution, this whole article is moot. Even if they said now that you can't build binary distributions, according to the licensing you could anyways. In the US, you can't enforce an "illegal" contract or agreement. The whole issue is moot and dead. That's why debian-legal has no clue what they are talking about, and it's why SourceMage GNU/Linux (I was former Video section maintainer), allows MPlayer into our grimoire. It's a no-brainer, really.

Seth Woolley

The Problem...

[WPIDalamar]

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.

Re:The downfall of debian

[Just Some Guy]

In gentoo you don't have to go off and find different sources for debian deemed "non-free" or "non compliant" packages...

You mean, the ones that the Debian installer asks if you want to add when you first configure the system? Are those the hard-to-find "different sources"?

To "win the desktop" linux has to give users the ability to easily get the programs and packages that they need and want to use.

Debian does a terrific job of providing the packages that they are legally and ethically allowed to provide.

Sorry to rant, but I've noticed more and more lately how debian's philosophy is getting in the way of me getting the programs I want to use.

If that's the case, then you shouldn't installed Debian in the first place. The Debian Free Software Guidelines are published and clear; if you don't agree with their philosophy, you're quite free to install another completely free professional-quality distribution.

On the other hand, I love Debian for the exact reason you do not: I know, beyond the shadow of a doubt, that I am 100% in license compliance with every piece of software on my system. I'd almost welcome a BSA audit - it'd be fun to yell "IN YOUR FACE!!!" every time they get snippety.

I'm afraid I'm missing the big deal here...

[Omega]

So after reading the whole thread it looks like the final outcome can be one of two possibilities:

• Either MPlayer adjusts its code and licenses to conform to Debian's rules in order to be added to the Debian distribution
• Or MPlayer doesn't change anything and they don't get included in the distro

So why the flame war? It's Debian's distro, they can set the rules as they like. Likewise it's entirely MPlayer's decision to conform or break Debian's distro rules. And if MPlayer doesn't want to be included in Debian, nothing stops users from compiling MPlayer by source and adding it to their system, right? It's not the end of the world if a program isn't available by apt-get.

Obviously if someone wants to fork MPlayer and create a version that is "Debian-able" they are certainly allowed to do that under the terms of the GPL. So I'm not quite sure why everyone's up in arms.

Re:I'm afraid I'm missing the big deal here...

[dinivin]

The issue, as pointed out by the Mplayer developers, is that Debian isn't consistent in the enforcement of their rules, making them seem quite hypocritical.

Dinivin

Re:I'm afraid I'm missing the big deal here...

[Xtifr]

The issue, as pointed out by the Mplayer developers, is that Debian isn't consistent in the enforcement of their rules

Debian makes mistakes -- everyone makes mistakes. But Debian usually tries to correct those mistakes. Back when Qt was GPL-incompatible, Debian briefly had KDE in the archives, which was a mistake. When someone pointed out the licensing problems, KDE was removed. At which point, the KDE folks went ballistic, and started shouting about how Debian was inconsistent and hypocritical because they had GPL'd packages using libForms (another GPL-incompatible library), and that proved that Debian had it in for the KDE folks, and it was all some evil plot. Unfortunately for this theory, Debian simply agreed that they'd made another mistake by accepting those packages, removed them, and that was the end of that.

Debian can be a little slow-moving at times (a common problem with all-volunteer groups), but if the complaints about Xine are valid, then I have no doubt that Xine will be gone (or fixed) soon enough.

Their arrogance and elitism are astonishing...

[dnaumov]

This flamewar once again shows the arrogance of the MPlayer developers:

> A user who can install a working xine package in 3 clicks won't care it runs
> 0.001% slower, if it just works.
A user who wants a movie player to install with 3 clicks can go use windows.

> Mplayer has unique features some people want to see in Debian, but if the
> legal status is still unclear, it just won't be done. Full stop.
Cool, at least we won't have to listen to the bugreports of binary package
users.

> Oh, yeah, you must think people wanting to use mplayer should make the
> effort of building it themselves, being rewarded of their efforts by
> having a working video player.
I know our opinions differ here, but YES.

> Then you are just a fucking elitist.
Unfortunately not, I only want to be :)

Those are just a few quotes from Gabucino, an MPlayer developer posting to debian-devel...

Re:Their arrogance and elitism are astonishing...

[stor]

Doesn't suprise me in the least. These MPlayer dudes obviously think that they are doing something pretty special. Sad thing is they obviously can't write decent code that doesn't require a -O 1337 compile-time optimisation.

MPlayer will fade into obscurity (like XAnim has) as more capable developers e.g. Xine developers and Gstreamer developers write software that Just Works. The Gstreamer framework will be integrated into Gnome soon 8)

Cheers
Stor

Re:Their arrogance and elitism are astonishing...

[Dr.Dubious DDQ]

"Arrogance", no. "Intolerance", yes. I think if I were subject to the amount and kind of abuse heaped on them by people who don't agree with the focus that the MPlayer project has, I'd get pretty terse with people, too. Especially people emailling to say "you are just a fucking elitist"...

Think of it this way. Imagine you're a volunteer developer. Now imagine you're ALSO the tech support for the project.

NOW imagine some third party packages your project with their distribution.

Your phone starts ringing. Your email goes nuts. They're all saying "Your program is broken/deleted my files/raped my dog/etc.".

At first it's easy to be polite. "You say it doesn't work? Can you give me a description of what it's doing wrong? Um, I'll need more detail besides 'it doesn't run', does it give an error message of some sort? No? What does it do? Oh, it DOES give an error message. Can you tell me what it says? No, I mean read what it literally says...."

Not only does this sort of thing REALLY grate on any rational person's nerves very quickly, but it's extremely time-consuming to deal with and prevents you from actually DEVELOPING anything.

Having lurked on the MPlayer user mailing list for some time, I find myself actually somewhat sympathetic for the MPlayer developer's hard line on dealing with things like this.

Consider what MPlayer is SUPPOSED to be - the most capable and efficient media player available for *nix systems. This focus has never BEEN "make it pretty and simple", but rather "make it effective". This is an important point - everyone harassing the MPlayer team with demands (and they often are - "you have to make it easier to use", "this software cannot continue like this", etc.) are, in effect, trying to "hijack" the project into a different focus. MPlayer ISN'T XINE and isn't supposed to be. The Xine project IS more focussed on user-friendliness than MPlayer. That's by design.

The friction the MPlayer project seems to attract seems to come entirely from people who think they should change the focus of their project from what the DEVELOPERS want to what the complaintants want. This, to my mind, is silly. Xine is much simpler to use. If "simple to use" is what you want, Xine is the program you want. If you're willing to read some documentation and deal with slightly arcane and very flexible command-line arguments in exchange for broader capability and somewhat better performance, then MPlayer is what you want. Choice is good.

I think the "Xine vs. MPlayer" alleged war is about as real as the "Gnome vs. KDE" one, which is to say, not at all except for a few peripheral folks who THINK there is one. Xine and MPlayer seem to cross-pollinate ideas well enough. The Xine project figured out Sorenson 1 and wrote a native decoder. MPlayer said "great work, thanks" and incorporated the concept into MPlayer (Giving full credit to Xine, as I recall). They, in turn, managed to puzzle out use of windows DLL's to get Sorenson 3 decoding capability. From what I can see, I think this is now in the most recent Xine releases as well.

It's all good. Everyone relax. Nothing to see here....

Re:looks like a messy "debate"

[Ogion]

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?

Re:GPL is not "free"

[TheCarp]

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)

Re:The downfall of debian

[digital photo]

The problem, I think, is the fact that people don't really grasp that there are pragmatic differences of belief along with legal ones between the different distros of GNU/Linux.

With Debian, they are trying to create a distro which is GPL compatible through and through. And the thing is, if that means not including something in their distro, then they are not including that something. All to keep the legal issues of their distro as clean as possible.

This isn't saying that Debian is sacrificing quality, if anything, because of their approach, their distro probably works quite smoothly and efficiently.

Nothing prevents you from acquiring the packages you want to use. They are only enforcing their right to not include packages and/or softwares which violates their license and/or sense of what is right/wrong.

It's just a different way of seeing to how things work.

I've switched from Slackware to Redhat. From that to Mandrake. Then from that to Suse, which is what I'm currently using. Now, I'm thinking of switching to Debian.

Will the restrictions they have on the default distro hinder my experience on my Linux box? Probably not. If I need code, I certainly know how to go and perform the "download, configure, make and make install" dance. I'm no stranger to coding and software installations.

The point is, there will be people who value one facet of life greater than another. Some people could care less about licenses. That's fine. Just understand that there are those who do.

Not just licenses, but philosophy, ethics, morals, and laws.

Re:The downfall of debian

[sweetooth]

You really need to read the Debian social contract before ranting about what they are doing. The primary goals of the distribution are quite obviously differant from what you are looking for and you will probably be better served by another distribution.

If you want Linux to "win the desktop" then you should make that your priority and work in that direction, but please don't assume that is the goal of every Linux distribution under the sun. Debian is a quality distro that attempts to adhere to a fairly strict set of standards. I personally appreciate that they adhere to those standards because it's one less thing for me to worry about when using the distro.

GPL isn't a law.

[Gadzinka]

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.'

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

Re:GPL isn't a law.

[rhavyn]

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.

Re:frightening

[Just Some Guy]

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.

Who is this nebulous "we" that thinks of proprietary software houses as "enemies"? Most software in the real world is non-Free, simply because most companies have no interest in releasing their widget-manufacturing software to the world, primarily because noone has ever asked for it. I've written custom software to track candle inventory; I don't recall seeing "candlewarehousing" as a category in the FreeBSD ports system.

Mplayer is a great program, and has made many contributions to the community and innovations to media applications in general (QuickTime, for example).

I wasn't aware that Mplayer is an Apple product.

Do not forget that mplayer is a powerful tool in our battle against those who would destroy us.

Adjust your tinfoil hat, or grow up.

Re:The downfall of debian

[Jason Earl]

Ethics...smethics. The best thing about Debian is that they take a good hard look at the legal aspects of each software package so that you don't have to. If something is in Debian main then you can be pretty sure that someone with a clue has taken a gander at the license, and that is a big deal.

Folks can pretend that technical issues are more important than legal issues, but that's just not true. The software packages that don't pay attention to the legal issues eventually get tripped up by them. For example, think of all of the pain and agony that KDE could have saved if they had been careful about the licensing issues right from the start.

Re:The downfall of debian

[Captain Rotundo]

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)

Re:The downfall of debian

[MBCook]

I too, used Debian for a long time; and I too now use Gentoo. But, the fact is that your missing the point. Debian is free. Debian is COMPLETELY FREE. AFIK, it's the only true FREE distro, in that they don't include anything that's not free.

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.

GPL Paradox -- appropriate response?

[Black Copter Control]

If a piece of software would otherwise violate the GPL, then source-only distribution is pretty much the only answer.

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.

Careful there...

[dark-nl]

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.

Re:The downfall of debian

[legLess]

Debian is great, but their ethics get in the way of putting out a first class distro.

Depends on what your goals are, doesn't it?

Anyone else think that debian is getting a bit anal in these matters?

"Getting?" Since when have Debian not been anal in this way? Their charter and policies are pretty clear, I think.

To "win the desktop" ... If granny has to figure out ...

This is all true, and all completely beside the point. There are few distributions more ill-suited for Granny than Debian. This has been true since Debian's inception, and will likely be true for quite some time to come. It's by design: Debian is for people who want a heavily-customizable, very stable, free, and Free OS. If you want "Granny-useful," pick another distro.

violation of blah blah charter blah blah ... legal flame wars about how paragraph 32 line 8 words 14-18 in the program license

No offense, and I'm sure you realize this, but the fact that these issues appear to you to be "blah blah" is another indication that Debian is not for you. That's fine - there are many other distros that do what you want.

Sorry to rant, but I've noticed more and more lately how debian's philosophy is getting in the way of me getting the programs I want to use.

This is a result of more and more people developing software for Linux, not Debian's changing policies. Yes, they're anal; yes, they're legalistic. However their goal is a lofty one - be the Galahad of Linux distros. If you don't share that goal, use another distro and God bless you. But don't flame them for standing firm by the principles they've used, publically, since the start.

MPlayer - packaging - debian

[jjermann]

Hey men!

What has become of Slashdot? Is it really a non objective flaming pool? Did nobody care to take at least a _short_ look at it before commenting stuff?

I took a _quick_ look. IIRC it's about the following:

1. binary packages of MPlayer in general
2. debian packages made by Marillat
3. license issues of MPlayer (GPL)
4. patent issues of MPlayer
5. why is xine in debian and MPlayer not?
6. Gabu's "stile of speaking"

I (almost) didn't see any objective statement about it so far, just crap. :(

1. There exist binary packages of MPlayer (see http://www.piorunek.pl/~dominik/linux/pkgs/mplayer /)
Their attutude is: Better no packages than bad packages as they have to read all bugreports about them (not the distributions). IMHO they're right.

2. They work to get good debian packages, Marillats packages were refused because at the time he provided them, they were illegal and full of bugs. We still get lot of complains by ppl using Marillats packages...

3. The developer really worked hard to get a 100% GPLed software. Many issues (like libmpeg2 and xanim(?)) are solved through mails with the authors.

4. There are mpeg4 patent issues with libavcodec.

5. But: the exact same issues apply to xine!! (e.g. it uses libavcodec too)

6. no comment, just stay objective ;)

What I wanted to say: Please stay objective and don't start to write crap....

Re:GPL is not "free"

[HopeOS]

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

Re:The downfall of debian

[colinleroy]

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.

Makes sense to me

[prockcore]

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)

Re:frightening

[Xzzy]

> 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,

The world isn't black and white, it has shades of every color. Arguments like this, the self policing of the open source community, will in the long run make open source stronger.

I wouldn't have it any other way, sometimes the best way to get a problem solved is to bruise some egos.

And Mandrake use PLF

[mickwd]

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.

Re:And Mandrake use PLF

[G�tz]

I'm currently maintaining the MPlayer packages for Mandrake and PLF. I must say that I hardly ever get complaints about missing features or problems caused by the runtime CPU detection.

The package in PLF contains almost every feature available in MPlayer and the only trouble people have caused by forgetting to add the Mandrake contribs to their urpmi sources, because they simply don't reat the FAQ on the PLF web site.

BTW I like the name and the logo, but of course I tolerate your different taste.

Re:What a clusterfuck

[jbolden]

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...

it ain't?

[zogger]

--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.

Re:it ain't?

[chromatic]

Your understanding is incorrect. See Does the GPL allow me to sell copies of the program for money?

Re:it ain't?

[chromatic]

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.

Sorry, this doesn't work

[JoeBuck]

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.

Re:The downfall of debian

[jazman_777]

Ethics...smethics. The best thing about Debian is that they take a good hard look at the legal aspects of each software package so that you don't have to. If something is in Debian main then you can be pretty sure that someone with a clue has taken a gander at the license, and that is a big deal.

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?

You are completely mistaken

[DennisZeMenace]

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

Re:GPL is not "free"

[Jason1729]

My understanding of the GPL is that as soon as that person re-sells one copy of my code, their version becomes freely distributable and the person who bought it can give it away to as many people as they want. As far as I'm concerned, this is good enough.

Jason
ProfQuotes

Missing the point

[TFloore]

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.

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?

Sorry people...

[protonman]

Hi all,

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 /. people. Skimmed the mailinglist a bit and wrote a little something on what I thought was the most "newsworthy" part of the flame war.

As it turns out, the issue is much more complicated than I made it look, and instead of entertaining the /. crowd with a insightful view on OS politics I did nothing but confuse matters more.

If I were an editor on this website, I would have refused my submission.

I'd like to apologise not only to the /. crowd, but also to the debian and mplayer developers whom this concerns.

Sorry again,

Protonman.

ps. Licence/License? I don't really care, I'm not a native speaker. :-P

my favorite quote

[Xtifr]

From the MPlayer home page:

Why does debian-legal think they know what is GPL and what is not better than Mplayer and XAnim authors.

Well, gee, I don't know, why would a bunch of people who study licensing issue on a regular basis think they understand licensing issues better than a bunch of people who are focused on writing code?

Having programmers look for legal problems makes about as much sense as having lawyers review your code for possible bugs.

A complete and utter non-issue...

[dinotrac]

The mplayer folks are entitled to package and license their software as they see fit.

The Debian folks are entitled to package and distribute Debian as they see fit.

Reminds of the KDE dustup.

That's when I switched from Debian to SuSE.
Glad I did.
Similar options abound for anyone who doesn't like the way Debian does things.

Re:The downfall of debian

[styrotech]

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.

Re:GPL is not "free"

[jaavaaguru]

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.

The Project From Hell

[Caiwyn]

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.

Re:The Project From Hell

[Anonymous Coward]

"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

The Mplayer team

[Anonymous Coward]

Now, I do respect their ability to code and all.

But the mplayer team (core from .HU), seem to have a rather shady side. For one, they come up with these ridicious arguments, making jabs at people and all.

From all this, I feel this is kinda like a publicity stunt, these people want to publicize mplayer by creating this whole cloud of negativity around it. It's simply not cool.

If you've ever posted on the mplayer mailing list, you'd find this attitude at the core. Mplayer developers (arpi and co) seem to think that they are gods, and that everyone else is wrong etc.. They are also heavly into warez and stuff on their .HU irc server (btw). If a newbie asks a simple question on their mailing lists, they would flame you to death, not only that, they would port scan you, and even try to enter some ports (for what reason? .. also remember arpi is one of the guys responsible for hungarian attacks on irc a few years back).

If you read their documentation (earlier ones) you'd see how less they understand the freesoftware movement. When they were not fully GPL, they had all sorts of crap about the FSF and GPL posted all over their site, things that no respectable software developer would even write. These people are simply script kiddies with no respect for the free software movemnet and community (as representated by debian).

I dont understand why they have to make such a mighty fucking issue out of all these things, just make the fucking software and let maintinaers package it as they wish.

Mplayer is very cool, but their ego is a bit too retarded. I hope they learn that they are not the greatest or biggest software team out there. I hope they stop this attitude. Also the posting on their main site seem like a declaration of war against debian (geez?!)

Ziel from the GNome I18N team.

Re:The Mplayer team

[Anonymous Coward]

1. Write Linux frontend for everyone else's codecs which are executed at runtime without the authors' permission, breaking numerous licenses.
2. Insult everyone who dares criticise the project.
3. Insult everyone who dares criticise you for insulting everyone.
4. ???
5. Profit!!!!

Rubbish

[kyz]

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.

Re:Rubbish

[DennisZeMenace]

But it has been done -- in Xine.

But Xine doesn't have 20% of MPlayer's features. You can't compare Xine and MPlayer in terms of code base. Still, i'm totally willing to agree that Xine has much cleaner code (i don't really know), but that doesn't prove much. Xine is certainly not more stable than MPlayer.

I stand corrected for the reverse-engineering aspect, though you make it sound strangely easy. Yet I don't see any open-source decoders based on those rev-eng efforts out there, even hosted in copyright-liberal countries. But anyway, f, however, reproducing the scrambling tables is illegal, then there's no perfect solution to this problem. So don't blame MPlayer's people for going to the easier DLL solution then!! All i want is a linux player that plays Sorensen v2 and 3 (and no, Crossover doesn't qualify).

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.

You make it sound like the MPlayer authors are just a bunch of code thieves, which is completely untrue. They wrote a lot of the codecs and work closely with a lot of the projects they borrow code from. Everybody knows ffmpeg is not MPlayer, nor is it Xine (which also uses it).

DZM

Re:Debian: stop whining

[AlXtreme]

Zealot here, and i too can burn some karma :o)

KNOPPIX wasn't made to install Debian, all that Knopper did was include a script (knx-hdinstall), made by Christian Perle, that works reasonably well.

Blow the debian installation into pieces? well, all it does is copy everything to harddisk. For i386. With far less flexibility. If you call that blowing into pieces then imho you don't get what Debian stands for: a free GNU/Linux distribution focussing on security, stability and flexibility, and not having the easiest installer on the planet or shipping broken unstable software.

And about mplayer: it's not the maintainers wanting it, it's the users asking for it :o)

Simple solution to the no-binaries issue..

[robbo]

1. Distribute the rpm or deb as a tar archive that installs in /tmp
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 /tmp/mplayer-src;
./configure --prefix=/usr
make
make install
cd /tmp
rm -rf ./mplayer-src

Gentoo

[Synn]

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.

Talk is cheap

[Kiwi]

I've reverse engineered decompression algorithms far more difficult than SVQ3's decoder.

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

Re:Talk is cheap

[Rares Marian]

Audio compression is lossy. DCT, wavelets, and psychoacoustics are PART of AUDIO COMPRESSION!

Re:GPL is not "free"

[Waffle Iron]

If someone took a freely available program and modified it and sold it, clearly they are selling the value of the delta/changes, NOT the value of the program which is no less freely avaiable to any and all.

That's what I tried to tell the federal agents when they came to confiscate the whole production run of my new video, "Mickey Mouse plays Twelve Favorite Metallica Hits", which I had produced and offered for sale on E-Bay.

Gentoo

[Helmholtz]

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.

Of course, mplayer works quite well with gentoo ... after all, it gets compiled when you emerge mplayer.

Re:GPL is not "free"

[DeadInSpace]

Debian does that. It provides a pine396-src package, which contains the source and patchfiles.

Licensing?

[Jeff Kelly]

I would consider the minor GPL violations the least of mplayers problems. What about the numerous video and audio formats they use without proper licensing?

Even if everything is reverse engineered then it would only save them from infringing on copyright but they would still have to pay the technology owners which means that at least mpeg-1 and mpeg-2 are out of the question ($ 2,50 per copy licensing fees). The same holds for several other formats which are not covered under a non commercial license.

I might get something wrong here but why can mplayer (and xine for that matter) use mpeg-1/2 divx, mp3 vivo and several other formats (including wma/wmv) without paying royalties to the respective copyright and patent holders and why doesn't anybody care about this?

May somebody please enlighten me about this issue?

Regards

Jeff

Re:Licensing?

[evilviper]

What about the numerous video and audio formats they use without proper licensing?

You will notice the ".hu" at the end of their URL. That tends to mean that US laws don't apply to them.

why can mplayer (and xine for that matter) use mpeg-1/2 divx, mp3 vivo and several other formats (including wma/wmv) without paying royalties to the respective copyright and patent holders

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.

Real men build from source

[quantum bit]

License prohibits binary distribution? Barely legal codecs that Debian can't distribute? No problem!

cd /usr/ports/multimedia/mplayer
make install

Yay BSD!

Not a legal problem, an attitude problem

[billstewart]

The Slashdot article hints that there's a problem involving distribution of binaries, but doesn't point to anything that lets you find it.
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.

not the first time

[nf]

the root of it all is that the mplayer team seems to want to protect their "brand name" in the same way that djb held a grip on qmail et all with his weirdo license (or lack thereof). they seem quite proud of mplayer's abilities and performance and the inclusion of a "crippled" mplayer in debian would certainly defy that. my suggestion was to create an mplayer debian package that can only play .au, just to piss them off. you'll notice there is no qmail/djbdns in debian or OpenBSD for similar reasons. (see http://www.linuxmafia.com/~rick/faq/#djb and http://www.sigmasoft.com/~openbsd/archive/openbsd- ports/200108/msg00461.htmlfor further clarification). instead of wacky configuration file pathnames and installation locations, the mplayer group seems convinced that their system for providing one binary for multiple sub-architectures is right.

but unlike djb, the mplayer group utilizes the standard GPL license (probably because they were too lazy to write their own crazy license) and seems to think they can utilize the GPL as a shield for protection of their illegal software.

in short, this isn't the first case of killer-app type software that is written by immature and/or wacky authors with questionable licensing terms (bitchx, qmail/djbdns, glftpd, vision-x, etc.)

if anything, their messages to debian-devel and the retalliatory flames are certainly entertaining reading.

Erm...

[Bert64]

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...

So, no MPlayer in Debian.

[soccerisgod]

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...