[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems

Josselin Mouette wrote:
> >  - staying legal (that bunch of sources was legal because each "libs" were
> >    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?

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

> You cannot distinguish binary and source redistribution this way. A
> derived work is still a derived work when you only provide the source.
"Derived work"? We are not talking about using GPL code in non-GPL software,
but exactly its opposite. We had a lot of miscellaneous licensed code mixed
up whose owners might have been mad if our software has just been "globally"

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

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

> 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? :)

> > Ehh ;)
> > Would you like an >500k diff included in the libmpeg2/ dir? :)))
> A changelog is not necessary a diff.
Huh? If someone wants that, he can do 'cvs -z9 log | less'
What reason would be sufficient to duplicate the cvslog? Don't you want
interlaced MPEG4 encoding more? (oh, DFSG... Well you can't watch movies with
that, can you.)

> 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
> should consider doing the necessary steps to make your software available in
> the binary GNU/Linux distributions.
In the last two years neither of us felt the instant urge to get MPlayer into
distros. And taking a look at freshmeat.net/stats and our download stats tells
us we are doing the right thing :)

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

> The Debian xine package doesn't use libavcodec (which is indeed illegal
> in some countries AFAIK).
LOL :)))
Then what does it use? Win32 codecs? XVID? Have you ever used libavcodec?

> > Success?
> You have indeed proven that someone wanting to package mplayer will have
> a hard time dealing with upstream.
Interesting, Dominik (our "official" RPM packager) works in close contact with
us, and never faced any hardships.. In fact, he is a developer with CVS write

It's just when people come up with such ideas as 100% legal, angel-white
distributions, that cut liba52, libavcodec, libmp3lame - and just can't
understand why it is Bad.

Just as Linus said on dri-devel, it would be better to go and _include_ things
with unclear legality (S3TC), and see if it matters to anyone, than go and
whine in the corner.

MPlayer Core Team

Attachment: pgp7v0XUZBXo4.pgp
Description: PGP signature

Reply to: