Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Debian Software Linux Your Rights Online

MPlayer Licence Trouble With A Twist 476

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."
This discussion has been archived. No new comments can be posted.

MPlayer Licence Trouble With A Twist

Comments Filter:
  • The simple fact.. (Score:5, Insightful)

    by Anonymous Coward on Wednesday January 29, 2003 @05:17PM (#5184309)
    ..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.
    • by rmadmin ( 532701 )
      I'd agree with this. I recently talked to a Radio Station about buying some new workstations from me. They had no complaints about running 20 machines with the same windows key. I strongly urged them not to, but they don't want to pay the fee.
      • Re:The simple fact.. (Score:3, Informative)

        by rilian4 ( 591569 )
        Using one code to install multiple copies of windows is perfectly legal if you purchase a corporate code from M$. It may not be cost effective with a small amount of workstations but the practice in and of itself is not a legal issue.
    • Re:The simple fact.. (Score:5, Informative)

      by DennisZeMenace ( 131127 ) on Wednesday January 29, 2003 @05:50PM (#5184611) Homepage
      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.. (Score:5, Interesting)

        by kyz ( 225372 ) on Wednesday January 29, 2003 @07:07PM (#5185253) Homepage
        The problem is, it's difficult to make good MPlayer binaries

        It's difficult to make good MPlayer binaries because MPlayer is badly written. Don't you get that? If the MPlayer authors actually cared about well-written software, it would use carefully crafted, modular APIs between all the component parts. I could add Quicktime codecs to MPlayer just by copying a hypothetical mp_qtime.so into lib/mplayer/codecs. Instead, it's a sprawling mess with files all over the place and a special codecs.conf acting as a central registry. Why can't each plugin tell Mplayer what capabilities it has, like Xine or XMMS does?

        MPlayer is famous simply mostly because it got Win32 codecs to work outside Windows. Kudos to them for doing so, but distributing other people's binary codecs is usually illegal. Apple don't permit you to hack into the Sorensen codecs and get them to work outside Quicktime Player.

        How would the like MPlayer authors like mplayer to be embedded as a binary in some media player, without source? Oh yeah, they whined like kiddies when that happened.

        I happen to write decompressors for various archive formats. Do I just take DOS binaries for those formats and hack into them to run them in Linux, then say "x86 only guys!"? No, I fully reverse-engineer the originals and write new depackers from scratch. The MPlayer team should do the same, and stop relying on other people's binaries for their glory.
        • Re:The simple fact.. (Score:5, Interesting)

          by DennisZeMenace ( 131127 ) on Wednesday January 29, 2003 @07:22PM (#5185404) Homepage
          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
          • Rubbish (Score:5, Informative)

            by kyz ( 225372 ) on Wednesday January 29, 2003 @07:49PM (#5185609) Homepage
            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.
            • Talk is cheap (Score:5, Interesting)

              by Kiwi ( 5214 ) on Wednesday January 29, 2003 @08:19PM (#5185818) Homepage Journal
              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 [uklinux.net], but there isn't an audio nor video codec to be seen. It all looks like LZW variants; lossy compression (DCTs, wavelets, and what not) is a completely different kettle of fish.

              - Sam

            • Re:Rubbish (Score:5, Insightful)

              by DennisZeMenace ( 131127 ) on Wednesday January 29, 2003 @08:46PM (#5186001) Homepage
              But it has been done -- in Xine.

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

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

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

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

              DZM
        • Re:The simple fact.. (Score:5, Informative)

          by blakestah ( 91866 ) <blakestah@gmail.com> on Wednesday January 29, 2003 @09:22PM (#5186255) Homepage
          Don't you get that? If the MPlayer authors actually cared about well-written software, it would use carefully crafted, modular APIs between all the component parts. I could add Quicktime codecs to MPlayer just by copying a hypothetical mp_qtime.so into lib/mplayer/codecs.

          You don't use Mplayer, do you? To add a codec, simply copy it to the codec directory. End of story. BTW, Mplayer supports all Quicktime codecs.

          Apple don't permit you to hack into the Sorensen codecs and get them to work outside Quicktime Player.

          Actually, so far, they have. The legal arguments are several.

          1) The binary is the same as Windows, and performs the same functions, and is freely downloadable from the provider. Apple. Provided the user does the download, no big deal.

          2) The code itself uses a plug-in architecture for Windows and Quicktime dlls, so that copyright issues on different sides of the plug-in interface are separated.

          So, Mplayer is GPL, but can still use Windows dlls, when they are available.

          The MPlayer team should do the same, and stop relying on other people's binaries for their glory.

          They DID reverse engineer SVQ1. And, others are coming, but until they are available, the movies may still be played using the Windows binary codecs, available via plug-in.

          Also, the source only re-distribution requirement is now gone, and the binary optimizes for hardware on the fly.

          Mplayer is a very impressive piece of software engineering.
        • Re:The simple fact.. (Score:3, Interesting)

          by kasperd ( 592156 )
          Apple don't permit you to hack into the Sorensen codecs and get them to work outside Quicktime Player.

          Who needs Apple's permissions? Where I live it is explicitly permitted by law, and the law even says that right cannot be given up by agreement.
      • Re:The simple fact.. (Score:5, Interesting)

        by pla ( 258480 ) on Wednesday January 29, 2003 @08:07PM (#5185746) Journal
        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.. (Score:4, Informative)

          by DennisZeMenace ( 131127 ) on Wednesday January 29, 2003 @08:57PM (#5186072) Homepage
          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
  • by philovivero ( 321158 ) on Wednesday January 29, 2003 @05:22PM (#5184351) Homepage Journal
    Not VNC, VLC. Videolan Client [videolan.org].

    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.
  • by Chacham ( 981 ) on Wednesday January 29, 2003 @05:23PM (#5184362) Homepage Journal
    That's why we use "unofficial" debs. Sometimes very scary, such as in Ximian. But, for mplayer this [marillat.free.fr] site does well.
    • by gibber ( 27674 ) on Wednesday January 29, 2003 @06:15PM (#5184849) Homepage
      One should note that this [marillat.free.fr] 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 [debian.org]

      • by den_erpel ( 140080 ) on Thursday January 30, 2003 @03:40AM (#5187658) Homepage Journal
        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.
    • But of course as the devs point out you *really* want to compile anyway. They include the Debian rules so it is pretty easy and fast. That is what I and most people I know do.
    • And Mandrake use PLF (Score:3, Informative)

      by mickwd ( 196449 )
      Mandrake packages who's legal or licencing status is uncertain are not supplied in the distribution.

      However, many are available (including mplayer) in Mandrake RPM format via PLF [zarb.org] (the embarrassingly-named Penguin Liberation Front).

      Instructions are even included for setting that site up as a URPMI repository ('urpmi' being Mandrake's equivalent to 'apt-get' - installation of packages, automatically resolving and installing dependencies). Note however, that some PLF packages require packages from Mandrake contrib repositories.
  • by Anonymous Coward on Wednesday January 29, 2003 @05:24PM (#5184375)
    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.

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

      • by Dr.Dubious DDQ ( 11968 ) on Wednesday January 29, 2003 @10:34PM (#5186612) Homepage
        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...

    • by billstewart ( 78916 ) on Wednesday January 29, 2003 @09:56PM (#5186443) Journal
      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 [mp.dev.hu] 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 [mp.dev.hu] 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 [fsf.org], 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.

  • by shepd ( 155729 ) <slashdot@org.gmail@com> on Wednesday January 29, 2003 @05:24PM (#5184379) Homepage Journal
    I'm not sure what, exactly, you are saying about MPlayer, considering they link [mp.dev.hu] to sites [piorunek.pl] with binaries.

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

    Sounds VERY fishy to me.
  • Emile van Bergen wrote:
    > Hi,
    >
    > On Mon, Jan 27, 2003 at 05:41:00PM +0100, Gabucino wrote:
    >
    > [SNIP]
    >
    >
    >>Uhh... Yes, it is GPL, but it is _not free_ (MPEG4, faad, etc) !
    >>Nor is MPlayer.
    >
    >
    > I'm quite anxious to learn your understanding of the GPL. I'm sure it's
    > most creative.
    >
    > Cheers,
    >
    >
    > Emile.
    >

    Pretty much sums it up. Gabucino also goes into a long diatribe attacking xine and never quite grasps that all that could potentially accomplish is getting xine removed and not mplayer added.
  • Honestly. I've been an mPlayer user for ages. In the past, the mPlayer people did not like for you to distribute binaries because it was difficult, if not impossible, to build binaries that would perform well on most x86 arcitectures. (So the story goes...) and they tried it (redhat, I think, was first) and got tons of flames and support requests on the mailing list beacuse the binary packages were flaky. It is part their code, lack of a good install script, and some other stuff, but they had a valid point. Especially when you link to external windows libraries and things like that-- it seemd to get real flaky if you had precompiled binaries (at least on redhat) though I'm told some crafty package maintaners have got it down-pat pretty good now. In the early days the mplayer authors didn't want to get a rep that their software was bad or flaky. The software was great... yeah the installer could have used some work, but...

    So befoe you flame them about a GPL, try to understand their (at least historical) reasons for asking this.

  • by hughk ( 248126 ) on Wednesday January 29, 2003 @05:31PM (#5184435) Journal
    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 [microsoft.com].

    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.

    • Just build mplayer statically - should solve dep problems (it would use more memory, but not significantly I would think).
      • by Cid Highwind ( 9258 ) on Wednesday January 29, 2003 @06:13PM (#5184825) Homepage
        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!!)
    • In debian (and perhaps gentoo), it is easy to get mplayer installed,

      # acquire
      wget ftp://...mplayer-link.../MPlayer-0.90rc3.tar.bz2

      # decompress source
      tar jxvf MPlayer-0.90rc3.tar.bz2

      # acquire useful directory state :)
      cd MPlayer-0.90rc3

      # [X] build a debian package
      fakeroot dpkg-buildpackage

      # fix various complaints about packages missing
      # (best to do this in another window; must be root
      # or apt-get set{u,g}id root, which is pure evil)
      apt-get install fakeroot libpng12-0-dev libgtk1.2-dev ...

      # do [X] again
      fakeroot dpkg-buildpackage

      # ... then
      cd ..
      dpkg -i mplayer_0.90rc3-0_i386.deb

      Whammo. You have mplayer. Ok, by "easy" I mean "repeatable sequence of commands", not "point and click", I guess. :)

      Cheers
      Brian
      - Just when Ih think I'm out .... they pulla me back in!
  • Solution: (Score:3, Informative)

    by dzym ( 544085 ) on Wednesday January 29, 2003 @05:31PM (#5184437) Homepage Journal
    Provide source for mplayer, such as a tarball .orig and then a patch, in Debian.

    You know, like how they handled UW PINE.

    • They wouldn't even have to include a patch, because mplayer is GPL minus the binary thing. They should handle it like they handle kernel sources.
  • by glenstar ( 569572 ) on Wednesday January 29, 2003 @05:36PM (#5184482)
    Think of different binaries for the possible combinations of MMX, MMX2, SSE, SSE2, 3Dnow, 3Dnow2. and then C code compiled for i386, i586, i686, k6 etc. and then think of non-x86 archs. and then debian can introduce the one-program-one-cd concept.

    That is from one of the mesages in the thread [debian.org].

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

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

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

  • We need Debian (Score:3, Insightful)

    by Dave W ( 1310 ) on Wednesday January 29, 2003 @05:37PM (#5184493) Homepage
    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
  • I work in the classroom support field of a major private high school in the US.

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

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

    The OS of Linux is great, but as for the extra flamebait cruft you see on the Debian list, that I can do without.
    • Debian can indeed be very political. I still don't understand their problem [debianplanet.org] with the GNOME/Bitstream font licensing agreement, for one.

      It's quite sad, really, watching innovation dies within Debian to be replaced by excessive political correctness. Debian used to lead in packaging (apt+deb) but now apt has been ported to RPM (see Conectiva [conectiva.com] and FreshRPMS [freshrpms.net]), Mandrake has uRPMi, and the Fink project [sourceforge.net] has co-opted apt/deb for binary distribution but added their parallel build-from-source-with-dependency system.

      I have packaged quite a few RPMs [sourceforge.net] in the past, mostly due to the lack of compatible RPMs after RH8 came out - but the horrible mess that is debian build scripts put me off. There are even some alternative packaging scripts for Debian, surely a sign of problems, but they never really take off.

      Here's my wishlist as an ex-Debian, soon-to-be Fink user (for the second time, my first OS X experience was held back by the lack of vector instructions in G3):
      - Peace among developers
      - Debian Desktop to succeed in making Debian more customer-friendly
      - Faster release cycles (I thought their new testing system was meant to do that)
      - Compile from source a'la Fink

      Peace,
  • The main gist.... (Score:5, Informative)

    by catch23 ( 97972 ) on Wednesday January 29, 2003 @05:40PM (#5184525)
    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.... (Score:5, Informative)

      by Anonymous Coward on Wednesday January 29, 2003 @06:06PM (#5184743)
      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
    • by DennisZeMenace ( 131127 ) on Wednesday January 29, 2003 @06:43PM (#5185083) Homepage
      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
  • The Problem... (Score:3, Informative)

    by WPIDalamar ( 122110 ) on Wednesday January 29, 2003 @05:42PM (#5184537) Homepage
    From reading the flamewar that is the news thread, I got this much:

    1) They use GPL & code under another license that isn't GPL compatible, plus their own code.
    2) They never distributed a binary.
    3) The released all that code.
    4) Their code had an added clause that states you can't distribute binaries.

    So the problem was, they used gpl & gpl incompatible code, so the resulting binary could not have been legal under any license. So they just simply didn't release a binary. I don't see a problem here. It's not against licenses to distribute GPL code next to gpl-incompatible code... it's just illegal to compile them together and distribute.
    • by JoeBuck ( 7947 ) on Wednesday January 29, 2003 @06:31PM (#5184998) Homepage

      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.

  • by Omega ( 1602 ) on Wednesday January 29, 2003 @05:46PM (#5184573) Homepage
    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.

    • by dinivin ( 444905 ) on Wednesday January 29, 2003 @06:21PM (#5184919)

      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
      • by Xtifr ( 1323 ) on Wednesday January 29, 2003 @07:31PM (#5185478) Homepage
        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.
  • by dnaumov ( 453672 ) on Wednesday January 29, 2003 @05:48PM (#5184589)
    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...
    • by Dr.Dubious DDQ ( 11968 ) on Wednesday January 29, 2003 @08:22PM (#5185836) Homepage

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

  • GPL isn't a law. (Score:3, Interesting)

    by Gadzinka ( 256729 ) <rrw@hell.pl> on Wednesday January 29, 2003 @05:51PM (#5184620) Journal
    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
  • If a piece of software would otherwise violate the GPL, then source-only distribution is pretty much the only answer.

    The GPL doesn't restrict what you can do with a piece of GPL code once you have it (to do otherwise would be a violation of the GPL). It only kicks in once you start distributing something with GPL code in it.

    Similarly, the GPL can't prevent someone from distributing their own source code, even though it would (if compiled and linked with GPL code) not be legal to distribute.

    In other words, if one feels that there may be GPL problems with their code, source-only distribution seems to be the appropriated thing to do.

    Telling people not to distribute binaries is simply a warning to prevent them from violating the GPL themselves.

    Not blatently sensible, and IANAL, but it seems to be legal.

  • by jjermann ( 514446 ) on Wednesday January 29, 2003 @06:16PM (#5184852) Homepage
    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....
  • Makes sense to me (Score:3, Informative)

    by prockcore ( 543967 ) on Wednesday January 29, 2003 @06:18PM (#5184878)
    This is what the debian people aren't getting:

    Some licenses are incompatible, even if they're all opensource. So what mplayer did was redistribute all the source, but you couldn't compile it together and redistribute it because of the license incompatibilities.

    Distributing license-incompatible source together isn't illegal because it's not "linking". License incompatibilities don't come into effect until you link them together.

    MPlayer does NOT have a license that says you can't redistribute binaries, but since compiling mplayer would link together incompatible licenses, that binary cannot be distributed without breaking the GPL.

    So debian was free to redistribute binaries, as long as they didn't create binaries that linked in incompatible sources.

    (This is about older versions of mplayer anyway.. the current versions of mplayer can and do have binaries being distributed)
    • Missing the point (Score:3, Informative)

      by TFloore ( 27278 )
      Some licenses are incompatible, even if they're all opensource. So what mplayer did was redistribute all the source, but you couldn't compile it together and redistribute it because of the license incompatibilities.

      If you can't legally redistribute, then most likely you can't legally compile it either.

      This is what you don't seem to understand. The binary result has the same license as the source. If the source licenses are incompatible, the binary is illegal.

      But it's okay it the user makes the illegal binary instead of the developers? This is your argument?
  • Sorry people... (Score:5, Informative)

    by protonman ( 411526 ) on Wednesday January 29, 2003 @06:58PM (#5185191) Homepage
    Hi all,

    This is the story submitter, and I must appologise for causing this much confusion. I read the blurb on the mplayer homepage and thought it would be interesting for you /. people. Skimmed the mailinglist a bit and wrote a little something on what I thought was the most "newsworthy" part of the flame war.

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

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

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

    Sorry again,

    Protonman.

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

  • my favorite quote (Score:4, Insightful)

    by Xtifr ( 1323 ) on Wednesday January 29, 2003 @07:01PM (#5185204) Homepage
    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.
  • by dinotrac ( 18304 ) on Wednesday January 29, 2003 @07:02PM (#5185218) Journal
    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.
  • by Caiwyn ( 120510 ) on Wednesday January 29, 2003 @07:27PM (#5185445)
    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.
  • by robbo ( 4388 ) <slashdot@NosPaM.simra.net> on Wednesday January 29, 2003 @07:59PM (#5185686)
    1. Distribute the rpm or deb as a tar archive that installs in /tmp
    2. make sure the rpm or deb depends on all the nifty things you want to include, as well as gcc.
    3. post-install:

    #!/bin/sh
    cd /tmp/mplayer-src;
    ./configure --prefix=/usr
    make
    make install
    cd /tmp
    rm -rf ./mplayer-src

  • Gentoo (Score:3, Interesting)

    by Helmholtz ( 2715 ) on Wednesday January 29, 2003 @09:09PM (#5186153) Homepage
    This kind of ranting, raving, finger-pointing, and concept that rules should be made with the intention to be used as clubs is the _exact_ reason I quit frequenting #debian. This has also played a role in my migration of almost all my boxes to Gentoo. Software runs faster, the atmosphere in #gentoo and on the mailing lists is much more amicable, and I think they have a better distribution concept.

    Of course, mplayer works quite well with gentoo ... after all, it gets compiled when you emerge mplayer.
  • Licensing? (Score:5, Insightful)

    by Jeff Kelly ( 309129 ) on Wednesday January 29, 2003 @09:14PM (#5186201)
    I would consider the minor GPL violations the least of mplayers problems. What about the numerous video and audio formats they use without proper licensing?

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

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

    May somebody please enlighten me about this issue?

    Regards

    Jeff
    • Re:Licensing? (Score:3, Interesting)

      by evilviper ( 135110 )
      What about the numerous video and audio formats they use without proper licensing?

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

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

      Well, besides their jurisdiction problem, there is also the matter of lawyer's fees. Take a look at the history of software patents... Unisys didn't give a damn about LZW until they noticed that there was critical mass, and people wouldn't be able to completely stop using LZW even if they wanted to. The same goes for the MP3 patents. They don't give a damn until there are large pockets from which they can pick.
  • by quantum bit ( 225091 ) on Wednesday January 29, 2003 @09:24PM (#5186263) Journal
    License prohibits binary distribution? Barely legal codecs that Debian can't distribute? No problem!

    cd /usr/ports/multimedia/mplayer
    make install

    Yay BSD!
  • Erm... (Score:3, Interesting)

    by Bert64 ( 520050 ) <bert AT slashdot DOT firenzee DOT com> on Thursday January 30, 2003 @12:22AM (#5187149) Homepage
    But not all of the code in MPlayer is based on other peoples gpl code, much of it is written by the mplayer team themselves... and any binary distribution of mplayer would require this code in order to function, so surely theyre well within their rights to request that people dont distribute binaries of THEIR code... I doubt they would complain if you built object files of the gpl`d code they reused from other projects, ofcourse on their own you wouldn`t have a very usefull program...
  • by soccerisgod ( 585710 ) on Thursday January 30, 2003 @05:40AM (#5187896)
    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...

"Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension!" -- Buckaroo Banzai

Working...