Re: MPlayer DFSG compatibility status
Glenn Maynard wrote: So this is not a problem - again. (I've had enough of Gabucino. Re-plonk.) Please no flames. If you think I'm wrong in something, please point me to the facts. -- Gabucino MPlayer Core Team pgpPT9Lajhrv8.pgp Description: PGP signature
Re: MPlayer DFSG compatibility status
Gabucino wrote: I wonder if there's still any obstacle in the way of MPlayer's inclusion into Debian. Please list _actual_ licensing problems of MPlayer so we can discuss them - the purpose this list exists for. The following issues' discussion has started so far: - libavcodec's possible patent infringements: even if they do exist, xine (which contains this library) was let into debian main. - ASF patent: it seems there is an agreement that there is no reason to fear Microsoft on this part. However - of course - I don't want to say the final word; this is just my understatement so far. - Win32 DLLs: current linux media players (including MPlayer) are more than able to live without them. While these topics can be important, I'd like if somebody would address my original concerns too. Thank you. -- Gabucino MPlayer Core Team pgpuEHO3p8Li9.pgp Description: PGP signature
Re: MPlayer DFSG compatibility status
Mike Hommey wrote: You forgot the non-respect of the license of the libraries included in mplayer (you know, the thing having been brought in another branch of this thread). I've checked the thread, but must have skimmed over it. Which is the library in question? -- Gabucino MPlayer Core Team pgplb6f79ZEyB.pgp Description: PGP signature
Re: MPlayer DFSG compatibility status
Josselin Mouette wrote: If we don't want to include this support, this is not your problem. E.g. xine in Debian has WMV9 support stripped off, and there would be no reason for mplayer to include it if there are legal issues with it. lol. Why is it stripped? It's done with the binary DLL. Another issue is that the xine authors have always been cooperative instead of ranting about this and that. Of course, if they are the favored side. maintainer will have a hard time convincing the ftpmasters that his package is 100 % free software, and free of patent issues. What about innocent until guilty ? Show me the nonfree part of MPlayer. -- Gabucino MPlayer Core Team pgp0GkzNSdd1C.pgp Description: PGP signature
Re: MPlayer DFSG compatibility status
Josselin Mouette wrote: As Gabucino mentioned, it can also decode WMV9 using the win32 DLL's, but distributing them is presumably illegal, so this is only a solution for those who have a copy of some Windows version on their computer. Then let's make it clear. - is xine's win32dll loader modified to deny loading WMV9 dlls or - just DLLs aren't distributed -- Gabucino MPlayer Core Team pgpG1k3IqPShP.pgp Description: PGP signature
Re: MPlayer DFSG compatibility status
Don Armstrong wrote: However, since they're generally not free software, nor (for the most part) are the even legal to (re-)distribute, we don't distribute them in Debian. (I'd strongly recommend that mplayer take a strong look at the DLL licenses if mplayer is distributing them.) We don't care of Win32 DLLs, because - contrary to the popular belief - they aren't useful anymore: libavcodec can decode _every_ popular format, except the WMV9 codec, but that's only a matter of time. Personally I use only one Win32 DLL, and only for nvidia_vid debugging purposes. So this is not a problem - again. -- Gabucino MPlayer Core Team pgpW8cvMQgN1O.pgp Description: PGP signature
Re: MPlayer DFSG compatibility status
Don Armstrong wrote: The most recent discussion is at http://lists.debian.org/debian-devel/2003/debian-devel-200307/msg01633.html Thanks, I've read all the related threads. It occurs to me that there were three issues brought up: - marking the changes made on imported libraries. This would currently include: libfaad2, libmpflac, libmpdvdkit2, libmpeg2. Let me clarify the situation. a, libfaad2 was commited to CVS because enermous amount of users wasn't able to either install libfaad and libfaad-dev, or read the MPlayer documentation about where to download libfaad sources. Effect: we received too much mails complaining about I can't hear anything in the new Matrix trailer etc. The decision was made to include libfaad2. Of course, MPlayer can be easily compiled with external libfaad dependency, and the internal one can be wiped out with a simple rm -rf libfaad2. Probably this is how it should be in Debian - thus this is not an issue. b, libmpflac has been introduced recently, because of the original library's idiotic libsndfile dependency. MPlayer is totally compilable without this, again, it's just an rm -rf. Probably this is how it should be in Debian - thus this is not an issue. c, libmpdvdkit2 is included so we have more area to make changes instead of sending patches back to its authors. MPlayer can be compiled with external libdvdread (and _optionally_ libdvdcss), just again: rm -rf libmpdvdkit2 Probably this is how it should be in Debian - thus this is not an issue. d, libmpeg2 is - of course - mandatory in MPlayer. It is developed by Michael Walken LESPINASSE, who we were always working closely with. We - the core developers - do not intend to waste time searching for modification dates and such (nor do we know what exactly you wish for), but if Andrea is willing to do this research, we'll most likely accept the patch. If any questions arise while this research goes on, I'll try to get answers to them. - another concern was the usage of statically linked libdvdcss. I've answered this above (it's deletable). - Sam Hocevar raised a concern about libavcodec. I do not intend to answer this, since xine was allowed into Debian with a full, included libavcodec. By the way, MPlayer also contains a LICENSE file, which - AFAIK - negliges the neccessity of GPL header inclusion in each of the source files. Any more concerns? -- Gabucino MPlayer Core Team pgpxE8y1YS3op.pgp Description: PGP signature
Re: MPlayer DFSG compatibility status
Glenn Maynard wrote: Sorry, that doesn't work. If the library has problems, it has problems regardless of whether it was previously allowed into the archive or not. Yes, someone here told you'd (all) be looking into xine's libavcodec issues. More than a half year has passed, and nothing happened. So I continue to disregard this matter. Xine's copy of libavcodec appears to include MPEG-2 video and MPEG-1 Layer 3 audio encoding. That may be moot if the code is never actually used, but encoders are explicitly enabled by -DCONFIG_ENCODERS, so this may not be the case. (It's probably a good idea to disable those anyway, though.) Huh? Why does xine use -DCONFIG_ENCODERS ? It can't even encode. And if you don't ship mencoder (that we can live with), you'll also don't have to define that. So this matter is (yet again) no problem. Oops. Looks like Xine has ASF support elsewhere, which is a problem. So? Is it going to be removed? If no, I continue to fail to see this as a showstopper. don't have an X machine to test whether this is really enabled in the package or disabled in some place I'm not noticing; I'd appreciate it if someone would check this. There is an aaxine version of xine. and VirtualDub had ASF issues. We won't agree to remove ASF support. It would be a most serious crippling. -- Gabucino MPlayer Core Team pgpRhLgxIfA9w.pgp Description: PGP signature
Re: MPlayer DFSG compatibility status
Don Armstrong wrote: d, libmpeg2 - We - the core developers - do not intend to waste time searching for modification dates and such (nor do we know what exactly you wish for), All that's needed is to comply with GPL 2a [and probably for any other GPLed libraries which you've included and modified from various sources in mplayer.] So is there anybody who wants to do this? -- Gabucino MPlayer Core Team pgpta26wvwLAO.pgp Description: PGP signature
Re: MPlayer DFSG compatibility status
Glenn Maynard wrote: One version of VirtualDub could read ASF files, and that was quickly removed. That was back in 2000, and I just checked: the news entries appear to have fallen off the site. There is a significant part to these patent enforcement stories: they all happen on Win32 platform. Microsoft has never enforced media patents on Linux market, as far as I know. -- Gabucino MPlayer Core Team pgp5LY9GP4zWO.pgp Description: PGP signature
Re: MPlayer DFSG compatibility status
Glenn Maynard wrote: Huh? Why does xine use -DCONFIG_ENCODERS ? It can't even encode. Don't ask me, ask the maintainers of Xine. I'd rather ask the .deb packager(s), because that is our current subject. Oops. Looks like Xine has ASF support elsewhere, which is a problem. So? Is it going to be removed? If no, I continue to fail to see this as a showstopper. Wow. You're certainly impatient. Here's a clue: we've just begun discussing this. Legal issues are not typically resolved in a day. This is nearly the exact wording that I received a year (?) ago. There is an aaxine version of xine. Okay, I can confirm that Debian's Xine has ASF installed. Uh-huh.. and VirtualDub had ASF issues. We won't agree to remove ASF support. It would be a most serious crippling. Which features will be disabled to permit safe distribution in Debian is ultimately not your decision. That is true. But one thing is certain. We don't want to receive the endless flow of mails asking about why the newest, apt-get'ed MPlayer doesn't play ASF/WMV files (a very significant part of the streaming media on the Internet). SuSE tried this road, and failed. They've removed their over-crippled MPlayer package 2 weeks ago. This attitude (forget the legal issues, we need this feature!) is precisely why Debian is so hesitant to go near mplayer. Debian actually forgets the legal issues in the case of xine (please don't argue, a year has passed since this argument of mine was raised first, and no effect to this very day), so *please* don't come with this line. I try my best to avoid another flamewar, but I need cooperation on your side. -- Gabucino MPlayer Core Team pgpg8Z5MYyIeA.pgp Description: PGP signature
MPlayer DFSG compatibility status
I wonder if there's still any obstacle in the way of MPlayer's inclusion into Debian. -- Gabucino MPlayer Core Team pgpYlbUv3yysv.pgp Description: PGP signature
Re: mplayer licenses
Josselin Mouette wrote: In case anybody's interested, I've just commited the GPLv2 'LICENSE' into CVS, to avoid further useless arguments. Could you please explain how the presence of a LICENSE file in a CVS tree affects in any way the copyrights and licenses of code coming from so many various sources ? Why would it affect anything? MPlayer uses only GPL, or GPL-compatible, or GPL-relicensed code. -- Gabucino MPlayer Core Team pgpSADpCbkSgK.pgp Description: PGP signature
Re: mplayer licenses
Josselin Mouette wrote: Could you please explain how the presence of a LICENSE file in a CVS tree affects in any way the copyrights and licenses of code coming from so many various sources ? Why would it affect anything? MPlayer uses only GPL, or GPL-compatible, or GPL-relicensed code. Did you really misunderstand such a simple question or are you answering off-target on purpose ? 1. If you think I misunderstood, please ask your question another way. 2. I don't like accusations. -- Gabucino MPlayer Core Team pgp63p0IJuCdh.pgp Description: PGP signature
Re: mplayer licenses
In case anybody's interested, I've just commited the GPLv2 'LICENSE' into CVS, to avoid further useless arguments. (not subscribed) -- Gabucino MPlayer Core Team pgpxdiM24T4om.pgp Description: PGP signature
Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
Don Armstrong wrote: There have already been numerous legal issues discussed in the mplayer saga, ranging from licensing irregularities to copyright problems and patent issues. That's fine to say, but if you let us know what they are, and we'll comment/fix them. So far there are libmpeg2 changes: we have no interest to fix that, as even libmpeg2 author Michael Lespinasse took part of it, so it's unlikely that he's gonna sue himself for his own code. MPlayer's debian package maintainer will have to fix that, as the spoken ChangeLog has no reason to be included in our CVS tree. And it will not be. Unfortunatly, no one in the mplayer team seems to think these legal issues are important False. AFAIR around 0.50 we checked our code for license infringing, and solved them either by contacting its author and requested permission for GPL relicensing, or by rewriting the code in question. If MPlayer is not 100% GPL (except lrmi.c, but that can be left out, sacrificing the very useful VESA video output), we are willing to fix it. Until that happens, mplayer will (probably) not be in Debian. Just be cautious, don't take an argument which also applies to xine ;) -- Gabucino MPlayer Core Team not sure how we will proceed here - xine's potential in the video processing field is imho so great that i certainly don't want to miss the chance to work into that direction. - Guenter, xine developer pgprUtyJClvhv.pgp Description: PGP signature
Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
Josselin Mouette wrote: it *will* be accepted. No matter how many stupid rants Gabucino can write Huh? I am not against MPlayer being included into Debian. no matter how crappy the code is, Uh.. MPlayer's code is crappy? Hm :) I already encountered performance issues on my 700 MHz Athlon system with mplayer. What performance issues? Kernel compilation is slow while playing DVD? I can play 800x600 MPEG4 movies on my AMD K6/2 500 without framedrop. We're waiting for your bugreport on mplayer-users. That is a fact. Seven hundred million is a measurable number : the number of cycles per second on that system. Then your computer has enough power to paste MPlayer's output to a text editor. -- Gabucino MPlayer Core Team pgpmEKItwPyaL.pgp Description: PGP signature
Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
Don Armstrong wrote: we have no interest to fix that, as even libmpeg2 author Michael Lespinasse took part of it, so it's unlikely that he's gonna sue himself for his own code. How can Debian be sure that that's the case? What do you need? A hand-written permission from Walken, photocopied 65535 times, and one piece sent to each goverment of the world for signature? I don't care if you don't believe me. Go ask Walken (M. Lespinasse) then.. Debian (correctly) avoids areas of questionable legality like the plauge. Uh-huh.. See below. How come the libmpeg2 issue wasn't caught? What issue? Do you disregard every mail? Convenient. Or the lrmi.c issue which you point out below? Wait a minute. So even to your knowledge Mplayer isn't completely under the GPL? Heh. If MPlayer isn't GPL because one of its video output driver (vesa) depends on lrmi, then what will happen to svgalib? Yes, Debian's svgalib also contains a VESA driver, and it uses LRMI for that. svgalib is included in Debian, however it isn't GPL. I wonder... Please don't stand further against me with your transparent ideas, or in the end everything will be stripped from Debian :) If xine is not free according to the DFSG or contains material which it would be illegal for Debian to distribute in countries in which major mirrors are located, then someone should file an RC bug against xine, so the issues can be discussed and a concensus reached. And who will file that? :) Nobody is mazochist here except you :) It would sadden me to see that happen, but that's the way things work. Only if you want it to be that way. -- Gabucino MPlayer Core Team not sure how we will proceed here - xine's potential in the video processing field is imho so great that i certainly don't want to miss the chance to work into that direction. - Guenter, xine developer pgpHmV3GZ7Ocg.pgp Description: PGP signature
Just the usual rant: Debian VS legal problems (MPlayer, xine, libavcodec)
Dear List. As some of you stated on debian-devel, xine in Debian doesn't include illegal parts. I have to assure you it _DOES_ . Take a look at libxine1.deb : 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. I'm waiting for your comments. -- Gabucino MPlayer Core Team pgpa4Ivfs1UkO.pgp Description: PGP signature
[arpi@thot.banki.hu: Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems]
Forwarded to debian-legal -- Gabucino MPlayer Core Team ---BeginMessage--- Hi, Sorry for not replying to teh thread, i'm not subscribed to this list. Gabu FWD'ed the thread and it seems that so many debian ppl thinks and says very false statements. So I have to tell you some comemnts and the truth. From: Gabucino [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems Message-ID: [EMAIL PROTECTED] Josselin Mouette wrote: - staying legal (that bunch of sources was legal because each libs w= ere distinctable, but _what license would you have given to the binary?_) This is not legal, at least when there the software includes some GPL code. So free speech is not legal? it seems that debian is not only speech... and we'll see that debian is also not free... but debian is actually a new OS/2 (half OS) edition. it contains thousands of programs but only half of each one, the other half was moderated out due to legality reasons :) so the users have to download the missing half from the net, breaking the law. debian's law. That doesn't prevent the binaries from working, using several packages with different cpu optimisations. Many packages in Debian already work this way. We call that method hack. And it's a big waste of space. 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. - we wouldn't have been #1 - people wouldn't have a working movie player EVEN NOW Wrong. No, true. I am not talking about the present. xine was (is?:) just a buggy piece of hunk that threw sig11s every minute, when MPlayer was the stablest movie player. :) The stuff I meant: half of the libavcodec and MPlayer developers are the same. They evolved together. If their developers behaved like debian developers do (no offense), we'd still be playing Indeo5 AVIs. or uncompressed ones. There have been several movie players around, which are much less painful to install and which comply with the DFSG - and they are included in the main Debian distribution. Amen. And they don't play any modern media file, but since debian is well known for many years old application versions and 'i'm using debian since 20 years' users it shouldn't be a problem... users (and mplayer developers) want an app which is able to play the films, trailers, advertisements, pron, whatever they download from the net. and we accept that it's at the boundaries of legality, when it comes for sorenson video, mpeg4 and such things. this is why we didn't expect (and didn't want) mplayer to be part of any distribution. users can download it and use it. shipping stripped down mplayer/2 with distros has no sense. just look at suse 8.1. it comes with mplayer, without mp3 codec, mpeg4 codec, asf demuxer and so on. it's a big unusable shit. and users keep complaining to us: when will be .asf support implemented? why doesn't it play my divx files? and so on. and they end up removing teh suse version and download the 'original' working one. suse could save few MBs of space and use for more nice kde3 wallpapers or sth. And even with all its optimize-everything-or-die crap, mplayer doesn't perform better. However, many people beg for its inclusion in Debian. Why? :) see my .signature for the answer... Ehh ;) Would you like an 500k diff included in the libmpeg2/ dir? :))) A changelog is not necessary a diff. It's an 1.2.1 cvs version. The changes were discussed with Walken (aka. Michel Lespinasse, current libmpeg2 maintainer) he even helped me with some things. Teh fact is that libmpeg2 was designed for OMS (nowdays called xine). Since teh architecture of it and mplayer differs a lot, it had to be changed, and he didn't wanted those changes in the official libmpeg2. Later he wanted, and the current 0.3.1 is very close to something we need, but tere are still a few problems, our patch is still waiting at mpeg2-dev list for commit. but it's gettig OT. So, i really doubt that he will sue us for using libmpeg2 with modifications. Huh? If someone wants that, he can do 'cvs -z9 log | less' Agree. I can even provide a small script called cvslog.sh which generates nice ChangeLog format text from cvs history. The resulting file is 1.8MB for whole mplayer now. I see no sense of including it with releases, everyone can get it for cvs. With all that willingness from upstream, this will indeed make things difficult. Life is difficult. : But if you want to be #1 (as your goal seems to be world domination), you we are already #1 but it doesn't matter, we make mplayer for ourself and not for idiots. A user who can install a working xine package in 3 clicks won't care it runs 0.001% slower, if it just works
