[MPlayer-dev-eng] MPlayer licensing [and lotso other stuff as I'm typing...]

[Felix Buenemann]

On Sunday, 25. November 2001 20:34, you wrote:
> On Sun, Nov 25, 2001 at 08:53:42PM +0200, Arpi wrote:
> > Hi,
> >
> > > > Until we make it possible to create usefull binary packages, we
> > > > shouldn't change the license. And after it's done, i'm unsure it
> > > > should be GPL. maybe other licenses (BSD?) are better for our needs.
> > >
> > > If what scares you about GPL is the "stealing" code, BSD allows to take
> > > the code, modify it, and sale the modifications in closed_source
> > > format, as the guys from russia are doing, even without mentioning a
> > > shit about you.
> >
> > ok BSD is bad too, in the opposite direction.
> > any other suggestion?
>
> You can't find ANY good license ... If you release your software with a
> license which allows someone to use your code WITHOUT releasing source
> code, they will do. If you want to force others to use your work ONLY
> within a project which respect your goals (freedom of your source for
> example) you will find yourself at GPL ... Well, almost :) [Similar to your
> kernel-and-driver problem]
agree.
>
> Arpi, think a bit. You were IDEG because you can't compile a non-GPL source
> into the GPL kernel. I think WarpVision authors were also upset that they
> can't compile in mplayer parts into "their" :) player without releasing
> source, including credits etc. (ok this is not exactly the same, but
> it's a similar situation). Simply there is NO such a license can be created
> which would be good for you. So I suggest use GPL _after_ we solved
> problems (like opendivx license included in mplayer).
>
small sidenode, this module is now available in a GPL version... (at least 
someone on /. mentioned it)

> My suggestion is to release MPlayer as 'almost GPL', let's see MPPL
> (MPlayer Public License :). Afaik, the problem conflicting opendivx and GPL
> (for example) are solved with releasing mplayer as 'source collection only,
> binary release is not allowed or something similar'. So try to make OUR
> codes as GPL. But let's release it as 'only source collection, disallow
> binary release, basically GPL'. With this move, we will need to eliminate
> the few non-GPL things from mplayer and after that it can be fully GPLed or
> other as we like.
>
I don't like this MPPL stuff, theres much smarter solution to our problems, 
that keep us from going fully GPL. We don't like binaries, that's the main 
point, because of known problems. Much better solution is to add some code to 
mplayer which solves this problems (as someone else mentioned, don't 
remember): we already have some cpu capability runtime check, we can use that 
to check if a binary was optimized for the current CPU, so let's say a 
mplayer binary was compiled for a Pentium-MMX and is run on a K6-2 it will 
give warning: "YOUR CPU SUPPORTS 3DNOW BUT IT IS DISABLED IN THIS BINARY, 
READ DOCS/BINARIES FOR MORE INFO!"
In case binary is compiled with cpu extension not available on current 
system, quit mplayer and give similar warning.

Now in DOCS/BINARY we can list the disadvantages of binary not compiled for 
specific system (tell about worse speed, possible crashes, ...).

Additionally we should add some ./configure --enable-dist that binary 
creators would be strongly advised to sue which changes version string into 
CVS20011127-BINARY (or whatever) and that will auto print a warning on using 
MPlayer stating: "YOU ARE USING A PRECOMPILED MPLAYER BINARY, READ 
DOCS/BINARIES FOR MORE INFO!"
We could also add here message like "DON'T REPORT ANY BUGS WITH BINARY 
MPLAYER!!!" or something along that.

This would also give us the advantage that MPlayer really see the sense of 
using self-compiled mplayer and don't only say: "They don't allow binary 
because they think it's shit/don't want newbies to use it/drink cola/etc."

If they are compfortable with their binary OK, otherwise they've been told 
what to do!
We IMHO also get alot less flames like that ;)

Btw. we also could add a sighandler for common crash signals to --enable-dist 
binary that tells people to try with selfcompiled cvs version first, before 
reporting bugs. (Maybe message: "OOPS MPLAYER CRASHED WITH SIGNAL NN! THIS 
SHOULD NOT HAPPEN! TRY TO COMPILE YOU OWN MPLAYER BINARY FROM (CVS) SOURCE - 
IF MPLAYER STILL CRASHES, SEND A BUGREPORT!")

IMHO people are more willing to believe stuff like this if they actually see 
it in the program and don't read it somewhere in the docs [lol users reading 
docs, as if that's ever gonna happen ;)] (like "uhm, docs say mplayer crashed 
on gcc 2.96, but it works for me, so they only write shit.")

> > > I _REALLY_ would like to know what you, Arpi, have against GPL, since
I think Arpi was pissed of by the prob he had with his kernel modules and 
that's the reason he now doesn't want to use GPL for his code... (just 
speculating can't read minds, yet)

> > > it has allowed you to use great peaces of code for making such a great
> > > program that mplayer is. With those projects in GPL you have been able
> > > to borrow the code and modify it, improve it.
agree.

> >
> > but it doesn't allow using non-GPL (but opensource, free) code in GPL
> > prg.
Are you sure about this? Surely GPL code may not be used in non-GPL code, but 
does GPL also say, that you may not use non-GPL code in GPL code? (As GPL is 
made to protect GPLed source, but not to prohibit GPLed code from using 
non-GPL code IMO). I might be wrong with this, maybe quote sentence from GPL 
that doesn't allow it. I should read GPL again, but it's quite long...

Btw. wasn't the problem with your module Arpi, that it didn't contain the 
licensing info yet, that was introduced in newer kernels. IMHO this may also 
be something else then GPL but still will load into the kernel, only modules 
_without_ license tag will refuse to load.

> >
> > and you are wrong, more than half of usefull code (codecs, demuxers etc)
> > aren't GPL.
hmm, demuxer of xourse isn't GPL, codecs are mostly loaded runtime, they 
don't matter and native codecs are mostly GPL.

>
> What? demuxer is copyrighted by you, you can change its license :)
> And codecs are external things so not covered by the license issue.
> (well, for example libmpeg12 and opendivx are another topic because they're
> included in the source, but afaik libmpeg12 is GPL, and opendix can be
> removed in the near future - at least according one of your letters).
>

> OK, imho there WAS a project to ask various authors to allow me to use
> their sources inside mplayer. Now let's start a project to try to convert
> all of the sources to MPPL and try to eliminate eg opendivx sources from
> MPlayer. And MPPL is 'basically GPL, but disallows binary distribution' or
> something similar. Then if we wish (no more compile time only feature
> select or something) we can change MPPL to GPL with only one simple line:
> MPPL=GPL ;-)
>
Well as said above, I don't like this idea and prefer the one I stated above.
But you should add the license you want your code licensed under, Arpi, to 
your code, for what you might use a modified GPL license until we sorted this 
out (I mean I don't like it, but it's better then not having a license in 
them at all).

> Well it's hard to write my thinks down :) but I hope everyone get the idea.
Hope so, too, not always easy to describe.

>
> - Gabor

-- 
Best Regards,
	Atmos
____________________________________________
- MPlayer Developer - http://mplayerhq.hu/ -
____________________________________________