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



Hi Thomas,

Thanks for your thoughtful response.  I hope we can come to a mutual
understanding of what makes sense for everyone.  Comments inline...

On Wed, 2003-12-10 at 13:17, Thomas Vander Stichele wrote:
> (cutting some lists out of the cc:)
> 
> Hi Rob,
> 
> > Which part of the Open Source Definition do you reckon the RPSL is in 
> > violation of?
> > http://www.opensource.org/docs/definition.php
> 
> 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".

If the OSI hasn't set the bar high enough, then I encourage you to go to
them and ask them to set it higher.

> > 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.
> 
> Reading that part again and again, it still seems to say that all
> copyright of anything contributed by people is assigned to real.  If
> this is not the case then please tell us what it is I am misreading, but
> quoting other parts of the license doesn't really change the fact that
> this part of the license seems to say so.  That is also what other
> developers I talked with seem to get out of it.  

We didn't want to be in a situation where someone could fork the code
without us having some recourse.  We're not worried so much about
small-time contributor in their basement, but it would really be bad for
some large, well-funded contributor to strip off our commercial terms
(the RCSL), and use our codebase to compete against us.

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....it seems like reasonable quid pro quo to
me.

> I will mail the gnome board as well asking them if they can get someone
> more qualified to translate the legalese for us.  But if you want to win
> us over I guess you should start by explaining why this bit of the
> license should be intrepreted differently.

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.  We've invested millions of dollars in
this codebase, and plan on investing millions more, so it seems rather
stingy to begrudge us a few extra rights.

For those making substantial contributions, we have a joint copyright
assignment:
https://www.helixcommunity.org/2002/intro/contributor-agreement.pdf

Additionally, you don't have to license your contributions under the
RPSL.  You can license them under a compatible license.  See Exhibit B
of the RPSL:
https://www.helixcommunity.org/content/rpsl

> > So, regardless of the fact that RealNetworks, as the Licensor, can 
> > create proprietary applications, you have the right to continue to use 
> > the open source version.
> > 
> > There are plenty of examples of where this is happening with GPL 
> > software today.  For example, much of the code that Raph Levien wrote 
> > was facilitated by this funding model (http://www.artofcode.com/)
> 
> Right, so what you're saying is, every version that is put out under
> this license will always be usable as opensource and available.  That is
> in fact reasonable.
> 
> It also somehow implies that there might be a time when newer versions
> will not be opensource or easily available free.  Which might be where
> some people have problems.

This can happen even with GPL.  Example: SourceForge.  VA Software took
a package that they licensed as open source, and made a proprietary
product out of it.

We're just being explicit about our intentions.  We hope that the
contribution from the community will be significant enough to never make
us want to do that, but we owe it to our shareholders to keep our
options open.

> > > The GStreamer team is pushing hard to get an integrated and
> > > distributable media framework and we are currently trying to fund the
> > > development of Theora codec so that we can get a completely free and
> > > open solution for multimedia streaming/playback.
> > 
> > Actually, RealNetworks has funded the Xiph Foundation in the past:
> > http://www.realnetworks.com/company/press/releases/2002/xiph.html
> 
> I read the press release back then, I reread it right now.  It never
> offered specifics, but as far as I can make out it just entailed getting
> a Vorbis plugin written for Helix, right ? Which is all fine, but since
> the code for vorbis was out there under a well accepted open source
> license, it could have been done by Real itself.  What I'm saying is, it
> didn't really help the development of Vorbis, though I can see why it
> makes sense for Real to pay codec developers to develop plugins for
> them.

Look for more announcements on this front.

> > RealNetworks has a long history of being as open as the business climate 
> > will prudently allow, and I don't see any reason why this won't continue.
> 
> For me, and for a lot of other developers, the success of Helix, and our
> possible involvement in it, stands or falls with your license, what it
> intends to say, and what it legally says.  Most developers seem to get
> from the license that all copyright is completely transfered to real.  I
> think you know why this is not acceptable.
> 
> 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.  

> Also, from an outside view, it is not very clear how open Real has been
> in the past.  Looking at the actual situation, the real codecs are one
> of the last to not have been reverse-engineered in some project.  The
> least that could have happened is some opening of codecs well beyond
> their expiration date.  It seems to me that your sentence translates to
> "the business climate doesn't allow Real to be open in a way that is
> useful to us".  While you may disagree with that interpretation, you
> should realize it is one that many share and that you will have to
> dispell :)

The fact that you've reverse-engineered some codecs doesn't mean you've
reverse-engineered the patents out of the U.S. legal system.  Do all of
these reverse-engineered codecs come with a patent license?

We've actually got patent licenses for the codecs we distribute.  While
that may not be useful to open source software projects that willfully
ignore US patent law, it makes a big difference in the aforementioned
business climate that RealNetworks has to operate in.

> 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.

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, as well as access to a
number of open source codecs and datatypes (including Ogg Vorbis and
SMIL 2.0).  We plan to add more, and we welcome the contribution of
others.

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.

Rob

-- 
Rob Lanphier, Helix Community Coordinator - RealNetworks
http://helixcommunity.org http://rtsp.org http://realnetworks.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]