Re: dual licensing try 2

 --- D Richard Felker III <[email protected]> wrote:

> Dynamically loading GPL code does not get around the GPL. If your
> proprietary program is using the GPL code, it must be fully GPL or
> (a technicality here) you must refrain from distributing the GPL'd
> code AT ALL (since you have forfeited your rights under the GPL by
> not releasing your program under the GPL).

Hmm, so would a proprietary program be allowed to use mplayer G2 as
its "back-end"? If it is not, then that would clearly be more
restrictive than using mplayer G1, because it's fine to use mplayer
G1 in slave mode using a proprietary program (the way I understand
things).
I'm saying this without prejudice whether I think it's "right" or
"wrong" allowing a proprietary program to do that or not - though I
think that if there's people stupid enough paying for a simple
frontend, why not let them?

Anyway, I think we should get back to the question that A'rpi asked
in the beginning: What could be done to make mplayer G2 *THE* video
architecture for linux (or *ix in general)? And make it that not ony
for the users but for the companies too?

Let's try to evaluate what companies might want from such an
architecture then.

First, there's the (commercial) codec writers and filter writers.
The license of the mplayer core is probably not their concern, since
they don't need to use or change it (instead mplayer will use them,
right?). Of course it helps them if writing codec/filter interfaces
for mplayer is easy and doesn't change every once in a while (since
that means work (=money) for them). For the same reason, they might
want to be sure that it really is THE video architecture, because
otherwise they have to write several of those interfaces for
different back-ends. I'm not too worried about that though, because
of the performance and popularity of mplayer :-)

Then there's those wanting to write media players (basically
front-ends). I think there's probably two or three kinds of
front-ends they might want to write.

One kind (a and b) would a player that actually uses mplayer as its
back-end, but adds a certain amount of front-end functionality.
Simple players (a) might just be the user interface itself, looking
nice and having some neat playlist functionality etc., but basically
leaving file reading and processing and displaying completely to
mplayer itself. So all they do is pass file names.

Advanced players (b) might want to do more things that mplayer would
usually do, for example read the files themselves because they think
they can do better, or read from proprietary files/protocols, or do
the decoding themselves etc. Then they just let mplayer do the things
they don't want to do (only reading and displaying files, or only
reading or only decoding and so on). Of course mplayer would need to
be flexible enough to do that. Maybe to allow proprietary programs to
to both, the mplayer core would need to be LGPL then (as far as I
understand it).
This way, I guess mplayer would become something like DirectShow: A
back-end that you can use as much or as little as you want and that
is pretty universal. And if enough people use it, it's going to be
hard to imagine video on linux without mplayer G2 :-P

Then there's a second kind of media players, and that would be those
who want to do everything themselves. This is what I think A'rpi had
in mind. If you want to do everything yourself, they need to have a
player core, writing it themselves or taking (buying?) it from
someone.
This is of course only necessary if they are not allowed to
dynamically use a different core (your program is proprietary and the
core is GPL) or they actually *can* use it (your program is
proprietary and the core is LGPL or maybe it is possible under GPL?),
but it simply isn't enough for them. (Would it actually be possible
to use a GPL core if you access a LGPL lib that calls the GPL core?
Dunno.)
What you have to bear in mind though is, that if it isn't enough for
someone to simply use a core (which would be possible in the LGPL
case) and they instead buy it, the only reason I can think of why
they would do that is because they want to modify it or combine it
with your own proprietary code.
The question is whather that would really have the desired effect of
strenthening mplayer as a standard. Instead it might actually weaken
mplayer, because if someone adds their decoders to "their" core, or
changes interfaces etc., then they don't need to use "standard"
mplayer at all, and even could be incompatible. Well, at least that's
not what I think strenthening is. Sure, mplayers code is used, but
mplayer as a video standard doesn't benefit. In the worst case, even
their modified mplayer might become a proprietary "standard", if it
becomes popular enough (and benefits from the stability of mplayer).

If someone wants to use codecs and filters written for mplayer G2,
then they can still write their own application using them, without
needing mplayers core, because the interfaces are all open and not
patented and can be used by anyone, even commercial people. If
someone wants the functionality of mplayer in standalone devices etc,
it would probably be enough for them to link dynamically to mplayer
(if it were LGPL?) if it is universal enough. And changes to it would
come back to mplayer.

Well, that's my thoughts for now :-)
Florian


	
		
Mit schönen Grüßen von Yahoo! Mail - http://mail.yahoo.de