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

[Thomas Vander Stichele <thomas apestaart org>]

Hi Rob,

I appreciate the time you invest in answering to our thoughts.

> > It's not a matter of whether it is opensource or not.  It might very
> > well be certified and seem to be in line with open source, but ...
> 
> I respect the Open Source Initiative a lot, because they've taken the
> time to establish standards, instead of forcing everyone to have
> one-on-one case-by-case discussions of what does or doesn't "qualify".

I do to.  What I'm arguing is that we aren't so much worried whether or
not it is open source.  We are more worried about certain other
aspects.  The fact for example that the two licenses seem to be
incompatible with the GPL is a big problem for GNOME in general.

Anyway, I'm trying to get some statement on something more important to
me, see below.
> > > Quoting the portion of the RPSL that you quoted out of context is very 
> > > misleading.  For starters, I encourage everyone to look at the whole 
> > > license:
> > 
> > I also checked the whole license.  I don't really see how quoting only
> > part of the license (ie the part that Julien wanted to focus on) makes
> > that part of the license any less valid.

To clarify, the quote came from the terms and conditions that we get
presented with when registering on the site.  The two licenses seem more
or less fine as far as I can make out as a non-legal person.

However, it seems that once you are ready to register and download code
and what not, you get presented with a terms and conditions page
(https://www.helixcommunity.org/nonav/docs/TermsOfUse.html)
where the paragraph regarding ownership was lifted from.

Now, both Julien and I have tried getting an explanation of what this
paragraph means and why these terms are completely different from the
two licenses.  In one mail you quoted parts from those two licenses, but
Julien wasn't asking about those two licenses, he was asking about the
terms of use.

I asked for clarification of Real's intention with these terms of use in
my mail, but again the subject is evaded.  And I still have no clue what
those terms intend to mean, how they mean anything other than "Real owns
you when you submit code", and how you feel we should interpret it.

Let me repeat this part very clearly: we would like to know if the part
quoted in the previous mail from the Terms of Use are valid, intended as
written, and really mean that Real owns copyright on submitted code.  We
can discuss other stuff all day long but without an answer to this I
don't think you will get people going and submitting code.  So let's
clear that hurdle first.

> I'm not sure I see how this hurts a potential contributor.  Yes, we
> could use their code in a proprietary product, but it's not like the BSD
> situation where you can have total parasites who take from the
> community, and never give back.  This is a special right granted to us
> as contributors of the code....

As said, it all depends on whether or not the Terms of Use are valid. 
Start there.

> it seems like reasonable quid pro quo to
> me.

Right, and I might agree to some level :) On the other hand, you're not
trying to get you to develop.  You're trying us to get to develop :) So
it needs to seem reasonable to us.

> I'd be disappointed if a potential contributor turned away because they
> dwell too hard on the rights RealNetworks gets rather than focusing on
> the rights the contributor gets.

When courting a community that has built their whole reason of existence
around a legal invention that focuses on the rights each of the parties
gets in using software, it would be naive to think that potential
contributors would not dwell hard on the rights both parties get.

> > So possible routes, if this matters to Real, are:
> > a) change the license
> > b) explain to us what it is that we understand in the wrong way
> > c) go right ahead without us
> 
> It very much matters to us.  We'll consider (a), but a very strong case
> needs to be made for that.  It helps to finally be having these
> conversations on a helixcommunity.org list.
> 
> However, it's important that we explore (b) (rephrased: come to a
> negotiated set of common goals).  Competition is always good, but I
> think we're getting ample competition right now from other completely
> proprietary frameworks.  

You're misinterpreting point b) I was trying to make.  b) Is the very
simple and explicit question "Please explain to us why we are wrong in
reading that clause in the Terms of Use as 'give us your code, it's
ours'".


> > That is not to say Real is completely closed; but you must understand
> > that as free software developers we are wary of being used as cheap
> > labour on a project that is less free than another with the same scope.
> 
> I understand your concern.  We'll 'fess up to being a big stupid company
> who doesn't fully understand why people contribute to open source.  In
> aggregate, we're guilty as charged.

Heh :) I am never big on corporate conspiracies, so you won't hear stuff
like this come out of my mouth.  But I understand you're fighting an
image which is very hard to shake off, and much respect to you for that.

> However, we're not asking you to contribute to RealAudio and RealVideo. 
> We're asking to collaborate on a media framework.  It so happens that as
> a bonus for using our media framework, you get *legal* access to
> commercial-grade codecs that are available today,

I want the users of my framework to have access to them, not myself.

>  as well as access to a
> number of open source codecs and datatypes (including Ogg Vorbis and
> SMIL 2.0)

Haven't checked SMIL recently, but Ogg Vorbis has been accessible long
before Helix.

> So we are asking for contribution, but we're contributing in turn.  Not
> merely with more development, but in acquiring patent licenses,
> developing for other platforms, making business deals to get more open
> source contributors, etc.  We're making the licensing as liberal as we
> can, while still ensuring we can run our business in parallel.

This makes perfect sense to us.  This is also where we are very
interested.  I believe it was Bruce Perens who was quoted as saying the
crown jewels were missing from the Helix initiative.  I agree with him. 
How hard can it be to
a) make binary-only codecs freely available without clickthrough license
b) write a GPL/BSD/Real License/... API and library for using them

I'm assuming Helix does b) fine at this point, but I'm not going to
accept the terms of use presented to me on the site as a potential
contributor without some explanation.

So, repeating this for clarity: please explain to us in human terms the
intent of that paragraph in the Terms of Use.

Thanks for your time,
Thomas