[MPlayer-G2-dev] the awakening, license changes and so on...

[Gábor Lénárt]

On Wed, Aug 04, 2004 at 11:01:05AM +0200, Arpi wrote:
> > Why do you want to get commercial users onto MPlayer ?
> > Just for the sponsoring ? 
> 
> argh. no, of course.
> i just want to "legalize" (bad word for this, but i dont know the right one)
> video playback under non-m$ systems. most of the codec/container makers
> would port/develop their stuff for non-m$ systems, if they have any
> chance, ie. any usable API they can use, like quicktike or dshow on win/mac.
> unfortunatelly they don't have any 'standard api' under unix/linux, so they
> end up either not supporting unix, or they hack together some useless
> standalone player (see realplay, bink player etc).

I was criticized several times because of my strong conviction about GPL.
Some guys called GPL 'restricitve' and even 'not free enough'. Though I've
never understand the point. In my oppinion BSD _IS_ restrictive license
because everyone can 'steal' my work (if it's copyrighted under BSD-type
license) and use it her own software without the need of releasing the
source. GPL is good, because it try to create a community where you can
'insert' new knowledge to and where you can 'get' knowledge from. The
'price' of using GPL based code is to GPLize your code as well, so everybody
is happy. 

HOWEVER.

Talking about a media player, it's somewhat similar situation like Linux
kernel, where binary-only modules are ALLOWED (non-GPL piece of softwares)
in some cases. So, if someone only want to implement a certain codec for
mplayer G2 with using the STANDARD codec interface, the codec itself does
not need to be GPL software at all. Also, the design (API ...) of the codec
interface is documentation which is not licensed like software, so of course
it's free to implement a non-GPL player with the same codec API as G2 has.
It's important, since if someone write a binary only codec using G2's codec
interface, someone other may want to use that codec in her non-GPL software
as well.

This sounds compilcated, but at this point we're talking about GPLized G2,
and even THIS situation allows G2 to become the 'standard codec interface
standard' as in its API at least.

Sure, other ideas may result in dual-licensed source or even non-GPL, but
this require the permit of all of the authors of the mplayer source.

I only wanted to point that it's _NOT_ impossible G2 to become some standard
even if we're talking only about GPL.

Besides I don't read all of the source of softwares I'm using of course,
I often feel some fear about binary only kernel modules, codecs, etc, since
I've no chance to see the internals (well, you can of course but it's much
harder to do that with disassembling etc). I mean, if you can use some
standarized codec interface, an anonymous web page would offer free porn
videos in (imaginary) PORN format. That page also offers the codec in binary
only format for download. But that "codec" may be a trojan. Since it
contains excutable code executed by the player when codec is used, it's
quite dangerous. So strong control over these binary-only stuffs are needed.
And of course there can be binary-only demuxers etc as well, as loadable
objects by the player.

Some users would be quite happy with the situation where you can download
and use a certain codec from a website even with a single click in the
GUI. But one of the major reasons about the better security of Linux
is that you don't get a screen saver in an e-mail in ELF which can be
executed on ANY Linux distro. Several Linux newcomers (does only know
about the 'GUI') would happily click on ELF attachment to run, like on an
EXE in case of Windows. The only reason she can't do this NOW is that
the lower percentage of Linux in desktop market share and the great
variant of Linux distros which would require executables linked against
different glibc, different libs, patched kernels by different distros etc
...

If someone would create a standard which can be used at ABI level it's
also very dangerous from the view point of security because of the human
factor. The only meaning of my long writing is the need to restrict
the possibilities of such codec modules etc to ONLY communicate with
the player or so to avoid security problems.

> we currently support most formats through win32 DLLs run by big hacks in
> emulators. ok, it's a working (x86-only) workaround, but not a solution.
> the soultion would be native codecs.
> and dont tell me to rev.eng. every single dll, because it's also not a
> solution...
> 
> btw i wonder why m$ didnt notice this empty space, ie. the lack of a video
> framework uner unix, they could port their dshow/dmo api and let the
> companies port their codecs to it. so they could get monopol status over a
> free os when it comes to video playback :)

IMHO m$ have got problems now. Thay would be able to support Linux and/or
UNIX with some media stuffs (and with many others, eg porting Office)
to gain some share on the Linux/UNIX market. However they must consider
that this move also dismiss some complaint against using Linux/UNIX as
desktop: many people using Windows just for the need softwares depending
on Windows. At least I guess ...

- Gábor (larta'H)