MPlayer Licence Trouble With A Twist

The simple fact.. by Anonymous Coward · 2003-01-29 09:17 · Score: 5, Insightful

..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.. by rmadmin · 2003-01-29 09:30 · Score: 3, Insightful

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.

--

Can all fish swim?
Re:The simple fact.. by DennisZeMenace · 2003-01-29 09:50 · Score: 4, Informative

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.. by kyz · 2003-01-29 11:07 · Score: 5, Interesting

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?
Re:The simple fact.. by rilian4 · 2003-01-29 11:16 · Score: 3, Informative

Using one code to install multiple copies of windows is perfectly legal if you purchase a corporate code from M$. It may not be cost effective with a small amount of workstations but the practice in and of itself is not a legal issue.

--

...quicker, easier, more seductive the darkside is...but more powerful, it is not.
Re:The simple fact.. by DennisZeMenace · 2003-01-29 11:22 · Score: 4, Interesting

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.. by pla · 2003-01-29 12:07 · Score: 5, Interesting

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.. by DennisZeMenace · 2003-01-29 12:57 · Score: 3, Informative

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.. by blakestah · 2003-01-29 13:22 · Score: 4, Informative

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.

Obligatory VLC Reference by philovivero · 2003-01-29 09:22 · Score: 3, Offtopic

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.

--
fifth sigma, inc.

That's why we use "unofficial" debs by Chacham · 2003-01-29 09:23 · Score: 5, Informative

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

--
Have you read my journal today?

Re:That's why we use "unofficial" debs by gibber · 2003-01-29 10:15 · Score: 5, Informative

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 by den_erpel · 2003-01-29 19:40 · Score: 4, Interesting

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

There are other legal problems with MPlayer by Anonymous Coward · 2003-01-29 09:24 · Score: 5, Interesting

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 by Black+Parrot · 2003-01-29 10:10 · Score: 3, Interesting

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

--
Sheesh, evil *and* a jerk. -- Jade
Re: There are other legal problems with MPlayer by Dr.Dubious+DDQ · 2003-01-29 14:34 · Score: 3, Informative

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

--
Hacker Public Radio is our Friend

MPlayer links to sites with binaries... by shepd · 2003-01-29 09:24 · Score: 4, Informative

I'm not sure what, exactly, you are saying about MPlayer, considering they link to sites with binaries.

If they had a problem with distributing binaries, why would they link to them?

Sounds VERY fishy to me.

--
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC

Re:MPlayer links to sites with binaries... by HuruRudo · 2003-01-29 09:39 · Score: 4, Informative

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.

You really need to build it.... by hughk · 2003-01-29 09:31 · Score: 4, Insightful

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.

--
See my journal, I write things there

Re:You really need to build it.... by Cid+Highwind · 2003-01-29 10:13 · Score: 5, Interesting

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

--
0 1 - just my two bits

Re:GPL is not "free" by Jason1729 · 2003-01-29 09:36 · Score: 3, Insightful

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 by Dave+W · 2003-01-29 09:37 · Score: 3, Insightful

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 by chromatic · 2003-01-29 09:37 · Score: 5, Insightful

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.

--
how to invest, a novice's guide

totally missed point by DrSkwid · 2003-01-29 09:39 · Score: 4, Insightful

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.

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter

The main gist.... by catch23 · 2003-01-29 09:40 · Score: 5, Informative

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.... by Anonymous Coward · 2003-01-29 10:06 · Score: 5, Informative

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

Re:The downfall of debian by Just+Some+Guy · 2003-01-29 09:42 · Score: 4, Insightful

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.

--
Dewey, what part of this looks like authorities should be involved?

I'm afraid I'm missing the big deal here... by Omega · 2003-01-29 09:46 · Score: 4, Insightful

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... by dinivin · 2003-01-29 10:21 · Score: 4, Insightful

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... by Xtifr · 2003-01-29 11:31 · Score: 4, Insightful

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... by dnaumov · 2003-01-29 09:48 · Score: 4, Interesting

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... by Dr.Dubious+DDQ · 2003-01-29 12:22 · Score: 4, Insightful

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

--
Hacker Public Radio is our Friend

Re:GPL is not "free" by TheCarp · 2003-01-29 09:49 · Score: 4, Interesting

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"

Re:The downfall of debian by digital+photo · 2003-01-29 09:49 · Score: 3, Insightful

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.

--

Winged Power Photography

Re:The downfall of debian by sweetooth · 2003-01-29 09:50 · Score: 4, Insightful

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. by Gadzinka · 2003-01-29 09:51 · Score: 3, Interesting

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

--
Bastard Operator From 193.219.28.162

Re:GPL isn't a law. by rhavyn · 2003-01-29 09:59 · Score: 4, Informative

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 by Just+Some+Guy · 2003-01-29 09:52 · Score: 4, Insightful

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.

--
Dewey, what part of this looks like authorities should be involved?

Re:The downfall of debian by Jason+Earl · 2003-01-29 09:58 · Score: 5, Insightful

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 by MBCook · 2003-01-29 10:05 · Score: 4, Informative

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.

--
Comment forecast: Bits of genius surrounded by a sea of mediocrity.

MPlayer - packaging - debian by jjermann · 2003-01-29 10:16 · Score: 5, Insightful

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:frightening by Xzzy · 2003-01-29 10:18 · Score: 3, Insightful

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

Sorry, this doesn't work by JoeBuck · 2003-01-29 10:31 · Score: 4, Interesting

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:it ain't? by chromatic · 2003-01-29 10:33 · Score: 3, Informative

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

--
how to invest, a novice's guide

Re:The downfall of debian by jazman_777 · 2003-01-29 10:36 · Score: 3, Informative

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?

--
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.

You are completely mistaken by DennisZeMenace · 2003-01-29 10:43 · Score: 3, Informative

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" by Jason1729 · 2003-01-29 10:49 · Score: 3, Insightful

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

Sorry people... by protonman · 2003-01-29 10:58 · Score: 5, Informative

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

--
The man of knowledge must be able not only to love his enemies but also to hate his friends.

my favorite quote by Xtifr · 2003-01-29 11:01 · Score: 3, Insightful

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... by dinotrac · 2003-01-29 11:02 · Score: 3, Insightful

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.

The Project From Hell by Caiwyn · 2003-01-29 11:27 · Score: 3, Informative

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.

Rubbish by kyz · 2003-01-29 11:49 · Score: 4, Informative

making a perfectly modular approach while supporting so many different formats and codecs is easier said than done.

But it has been done -- in Xine.

Reverse-engineering is the perfect solution, but in practice it can only be done for simple things.

You clearly don't know how difficult (read: easy) it is to do reverse engineering. It only takes a skilled reverse-engineer (of which there are thousands in this world, most of them are ex-crackers), time and interest.

I've reverse engineered decompression algorithms far more difficult than SVQ3's decoder. Although I haven't seen it, there are rumours that SVQ3 has been reverse-engineered and posted anonymously to Usenet. They say it's just H.263 with some scrambling tables, so Sorensen can claim copyright infringement (of those tables) if anyone writes a decoder. All WMV and WMA codecs have been reverse-engineered. There is nothing mystical or special about a multimedia codec, it's just an algorithm like anything else.

One last example, the even more difficult Microsoft Media Player DRM has been flawlessly reverse-engineered (not by me), despite being actively encrypted and made difficult to run through.

The MPlayer authors are rarely the guys behind reimplementing codecs -- that's what the authors of ffmpeg (libavcodec) do. MPlayer just takes the glory by putting it all together.

--
Does my bum look big in this?

Re:Rubbish by DennisZeMenace · 2003-01-29 12:46 · Score: 4, Insightful

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

Talk is cheap by Kiwi · 2003-01-29 12:19 · Score: 5, Interesting

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

--

The secret to enjoying Slashdot is to realize that it should not be taken too seriously.

Licensing? by Jeff+Kelly · 2003-01-29 13:14 · Score: 5, Insightful

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:Well, look at their original reasons. by hklingon · 2003-01-29 13:26 · Score: 3, Informative

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

Not a legal problem, an attitude problem by billstewart · 2003-01-29 13:56 · Score: 4, Informative

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.

--

Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks

So, no MPlayer in Debian. by soccerisgod · 2003-01-29 21:40 · Score: 3, Interesting

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?

Slashdot Mirror

MPlayer Licence Trouble With A Twist

58 of 455 comments (clear)