Re: [gst-devel] Re: Helix Player virtual team meeting

[Thomas Vander Stichele <thomas apestaart org>]

> I would note that at this point we're not seriously committed to
> gstreamer. Yes, we like it, and yes, we use it, but for all real intents
> and purposes all of our important apps (mainly RB and totem) work with
> xine just as well or better, and presumably we could do the same with
> the Helix framework if it offered advantages (technical or otherwise.)

Well, no one here is going to find out if the Helix framework is a
viable alternative or not unless they download the code and agree to the
Terms of Use.  One thing that, with them being phrased as they are right
now, I'm not about to do.  The discussion seems to give me hope that
these terms will be changed at some point though, and then I will gladly
download it and try to learn what I can.

Besides that, after lots of legality discussions in the past, GStreamer
has tried to get all matters clarified regarding those issues.  We had
learned that the way GStreamer works (ie providing API and library to
access codecs that hook to other libraries of various licenses) makes
the legal discussions wrt GPL and LGPL slightly more difficult.  IANAL,
but the gist of it ended up being:

a) GStreamer needs to be LGPL-licensed as a library to be usable by
GNOME
b) It needs to be LGPL-licensed so it's ok for companies like Real or
Apple to make binary-only plugins and have them be used with GPL plugins

I don't know history from memory wrt this aspect, but at some point we
did a big license audit and made sure it was clear that GStreamer was
LGPL to comply with GNOME's direction.  I am not suggesting Helix should
be LGPL, because that would be silly, but I do remember it being a big
problem for GNOME whether or not GStreamer really was LGPL in both word
and meaning.

> So gstreamer should have to argue on the technical merits- 'it is
> already in GNOME' should not be good enough, or even a significant point
> in their favor. [Sorry, guys, you know I love ya :)

We know you do :) Anyway, agreed.  If GStreamer can't live up to its
promises it's a problem.  Which is partly why I switched jobs; to live
up to that promise.

> > It's a parallel effort, with different goals -- Gnome integration is
> > just a side advantage, and not the real goal.
> 
> The gstreamer guys have pointed out repeatedly that gnome integration is
> not their primary goal either- they'd like both KDE and GNOME to use
> them. :)

Well, yes and no.  Our primary goal is to be a desktop media framework. 
In that respect, GNOME integration is our primary goal.  All of the
below-desktop-level components can be used by any desktop.  The
GNOME-specific code on top of that to achieve full integration is
minimal.  So, GNOME integration *is* directly our primary goal, as a
part of our desktop integration goal.

Compare to GTK: while I don't think GNOME integration is GTK's primary
goal as stated, it probably wouldn't be worked on if not for GNOME.


> Just to be clear, I'm ready to accept binary-only stuff /only/ if the
> framework is Free, and /if/ the framework supports open/Free
> alternatives to all the binary-only bits. _if_ those goals are met, then
> frankly, I don't care what Real's 'ideals' are, or how many binary-only
> bits they ship, because if they try to screw us, we have the code, and
> we have alternatives.

I have yet to form an opinion on this.  On the one hand I agree - let's
get there the quickest possible.  On the other hand, GNOME is trying to
adhere to a goal where we get where we want to be without making too
many compromises, on all levels (That includes being pedantic about
configuration options, long-term solutions, and so on.), and I see no
reason why we wouldn't want to do the same for the media framework we
want to use.

Take my mail with a grain of salt, it's very hard for me to split up the
part of me that works on GStreamer and the part of me that works on
GNOME.

Thomas