Re: Helix player virtual team meeting

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

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