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

Arpi arpi at thot.banki.hu
Sat Jul 24 15:41:16 CEST 2004


Some of you already know from irc, i'm planning to continue work
ok mplayer g2 core from september. I left g2 because of the license
conflict: i don't like gpl, especially for the g2 core, and no, i
did not change my option, but the license :)

So i plan to change g2 core license to lgpl.
So no dual licensing, no commercial licensing and such mess.
LGPL should be better for a (set of) library(es) anyway, and
it let commercial users to link it with their optionally
closedsource UIs, drivers etc.
We won't get money directly (opposed to original dual licensing plan),
but as iive said, nobody wants money, so it should not be problem. :)
Although it can be expected that some commercial users (think of
settopbox, divx player etc makers) will sponsor some of you to do
custom development for them. I'm personally not interested much in
these, but i was asked by several companies in the past year
(including some quite big ones), so i know there is such interest.

GPL is just too limited for the purpose of g2 core. Even Michael and
Alex agreed on irc. We need some license which allows at least linking
to plugins and UIs under different (even closed source) license.
Why? Think of a 3rd party company developing codecs (like 3ivx, On2 etc)
they want to make their codecs available for linux (and other unix)
platforms natively (no DLL hack), but they cannot open the source,
or they can but they dont want to put it under GPL.
The second reason is commercial users, ie settopbox makers etc.
I was contacted by several companies in the past, with very different
targets of use. It ranges from driving 16000x4000 pixel giant displays
(using industrial 16-head vga cards), to driving 3-d hologram projectors,
or to be used in advertisement display kiosks in 24/7 for months without
a reboot/restart. They all need very stable linux-based player core.
And they all need less restrictive (than gpl) license.
Since these applications are far from as-is use, they usually need
custom plugins, uis, and they are willing to sponsor us to do that.
(note to Rich and friends: sponsoring not only means money, it may mean
added code/patches, hardware to developers, new server and so on)

the code released in g2 peview47 is mostly under gpl. it means
we need to change license, with the agreement of authors. so,
if you are author of some code in g2, and you disagree with the
lgpl, tell us asap, so we can replace your code.
note, that most of the code in g2 core is written by me, or being
copied/inherited from g1.
about plugins/filters: i want the basic ones (like swscaler,
crop/expand, libavcodec, vo_x11 etc) be lgpl too, so they can
be included in core. The rest (like Rich's filters) may be external
gpl plugins, unless their authors accepts lgpl.

the first goal is to stabilize/finalize all core APIs. most of them
are OK already, maybe needs some fixes or reviews, and documentation.
in details:
VO: the x11_helper stuff needs to be designed better, Beastd and Faust3
    promised some help me, and Koth too in the past.
    the driver api (buffer allocation, display etc) stuff is ok imho.
    also we should check how to handle "coupled drivers", like
    x11+vidix, x11+mga, fbdev+tdfx, vesa+vidix etc.
    either the parent driver can handle it, or the vf_vo wrapper can.
    both has advs and disadvs.
AO: the g1's libao2 should be ok, with changes to use module_t and
    do not use globals.
AF: it is not done yet at all, i have some plans but need time to
    implement. anyway AF layer can wait, it is not so important.
VF: i plan to use my code from pre47, and don't wait for Rich's
    vaporware. and as Rich will probably refuse LGPL anyway,
    it should not be a problem :)
OSD: i've made some drafts and code, have to check it again.
DEMUX: should be ok, except that i want to implement framer API,
     to handle raw formats like mp3 or mpeg-ps.
VD: should be ok, except the changes required for framer api
AD: depends on AF
CONFIG: layers 0,1 are (almost) ready, layer 2 should be implemented

So, as you already could see, i don't count with Iive's and Rich's work
on vo and vf layers. If they have complete, implemented solutions,
i'll check, but i wont wait for them forever and keep reading the
utopistic drafts with mixing multiple video streams etc.
I guess they should work on g3 instead :)

The goal for g2 is still the same: make it usable as soon as possible.
In short: no new from-scratch overcomplicated apis, and try to keep
some backward compatibility with g1, so plugins can be ported easily.
Think g2 is a cleaned up, extended g1, and not a new player/editor with
ultimate features.

i expect big flames about this, but please keep it short :)

A'rpi / MPlayer, Astral & ESP-team

MPlayer's new image: happiness & peace & cosmetics & vmiklos

More information about the MPlayer-G2-dev mailing list