Slashdot Mirror

← Back to Stories (view on slashdot.org)

MPlayer Licence Trouble With A Twist

Posted by timothy on from the life-is-messy-sometimes dept.

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

38 of 455 comments (clear)

  1. The simple fact.. by Anonymous Coward · · 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.

    1. Re:The simple fact.. by DennisZeMenace · · 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

    2. Re:The simple fact.. by kyz · · 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?
    3. Re:The simple fact.. by DennisZeMenace · · 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

    4. Re:The simple fact.. by pla · · 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...

    5. Re:The simple fact.. by blakestah · · 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.

  2. That's why we use "unofficial" debs by Chacham · · 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?
    1. Re:That's why we use "unofficial" debs by gibber · · 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

    2. Re:That's why we use "unofficial" debs by den_erpel · · 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."
  3. There are other legal problems with MPlayer by Anonymous Coward · · 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.

  4. MPlayer links to sites with binaries... by shepd · · 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
    1. Re:MPlayer links to sites with binaries... by HuruRudo · · 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.

  5. You really need to build it.... by hughk · · 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
    1. Re:You really need to build it.... by Cid+Highwind · · 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
  6. Re:The downfall of debian by chromatic · · 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
  7. totally missed point by DrSkwid · · 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
  8. The main gist.... by catch23 · · 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.

    1. Re:The main gist.... by Anonymous Coward · · 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

  9. Re:The downfall of debian by Just+Some+Guy · · 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?
  10. I'm afraid I'm missing the big deal here... by Omega · · 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.

    1. Re:I'm afraid I'm missing the big deal here... by dinivin · · 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

    2. Re:I'm afraid I'm missing the big deal here... by Xtifr · · 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.

  11. Their arrogance and elitism are astonishing... by dnaumov · · 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...
    1. Re:Their arrogance and elitism are astonishing... by Dr.Dubious+DDQ · · 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
  12. Re:GPL is not "free" by TheCarp · · 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"
  13. Re:The downfall of debian by sweetooth · · 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.

  14. Re:frightening by Just+Some+Guy · · 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?
  15. Re:The downfall of debian by Jason+Earl · · 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.

  16. Re:GPL isn't a law. by rhavyn · · 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.

  17. Re:The downfall of debian by MBCook · · 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.
  18. MPlayer - packaging - debian by jjermann · · 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....

  19. Sorry, this doesn't work by JoeBuck · · 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.

  20. Sorry people... by protonman · · 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.
  21. Rubbish by kyz · · 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?
    1. Re:Rubbish by DennisZeMenace · · 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

  22. Talk is cheap by Kiwi · · 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.

  23. Licensing? by Jeff+Kelly · · 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

  24. Not a legal problem, an attitude problem by billstewart · · 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