Re: Helix player virtual team meeting

[Bill Haneman <Bill Haneman Sun COM>]

I didn't want to jump in, but here goes.

I think the main issue here is licensing.  I think there's little doubt 
that supporting
the Real codecs in a nice interoperable way is something we'd like to see.

Arguing merits of various licenses is mostly noise in this context since 
we (GNOME)
have a set of hard constraints around licensing (GPL-compatibility 
primarily).  There are of course other issues, but I think we need to 
tackle this one up front.

> 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.
>  
Dual licensing is the usual way companies deal with this.  The copyright 
holder can choose to license under multiple licenses as long as none of 
those licenses claim exclusivity.  See TrollTech/Qt and 
Sun/StarOffice/OpenOffice for examples.  Some people dislike dual 
licensing but it beats closed-only any day IMO.  Dual licensing gives 
customers of the application/library two choices; invoke the GPL license 
and make their own product free, or invoke the alternative license and 
pay the licensor/copyright-holder a fee.  This would prevent competitors 
from leveraging Real's work (or GNOME's work) to Real's disadvantage.  
It also prevents proprietary value-adds in the absence of the more 
'commercial' license.

OK, please note IANAL and I am _not_ representing my employer here!  
That said, my opinion:

The patent issue is a little more thorny, unless the patent holder is 
willing to open the gates wide for a particular free implementation.  In 
most cases the best solutions are:
* avoid patented technologies in preferred codecs;
* create a plug-in framework that allows non-GPL-compatible modules to 
be created.

In practice this means IMO an LGPL plugin framework (since LGPL can be 
used with both GPL and most proprietary licenses) with an open-source, 
but non-free, plugin for the patent-encumbered codec.   Real may choose 
GPL for those codecs which don't require tougher redistribution 
restrictions, for reasons stated above, and those plugins would then be 
GNOME-friendly.  (The non-free plugins would have to be downloaded and 
installed from elsewhere by end-users, or bundled by distributors, etc.)

Making the plugin open source removes barriers to porting and 
platform-dependence, while allowing a license that is more compatible 
with patents (i.e. not freely redistributed without restriction).

Still, the preferred codecs and plugins on free desktop platforms 
(GNOME, KDE, Linux, etc.) are going to be the unencumbered ones for 
reasons that hardly need restating.  But the above technique can allow 
the heterogeneous real-world mixture of codecs and licenses to 
interoperate, (in my naive opinion).

- Bill