Re: [Flac-dev] Should FLAC join Xiph?

En réponse à Josh Coalson <[email protected]>:

> That is the question I put before you all tonight :)
> 
> (Short background, Xiph is the corp behind Vorbis and Ogg,
> among other things; see http://xiph.org/about.html .  I
> think Emmett is here now so correct any of this if it's
> wrong.)
> 
> I've been talking a little with Emmett Plant and Monty about
> this.  If it were to happen, it would mean the following:
> 
> 1. FLAC would benefit from the increased visibility from the
> association.  Emmett can probably expound more upon this point.
> Anyway, hopefully this will mean it's popularity will rise,
> not just with users but also with developers of other tools.

Actually Xiph is getting more and more popularity among the "open" world. I
would just like to put your attention on another "company" that is trying to
fuel the open community of multimedia. It's CoreCodec, which is meant to be the
"Sourceforge of multimedia".

Of course it depends on what your implementation means. But if it's just to make
sure than any OGG player can play audio using the FLAC, it's fair.

But as an MCF related person (I actually make the design of the format and code
the parsing library), that would mean you put all your attention on the OGG
container and the Xiph API for codec. And I'm really concerned about that
because FLAC was on my top priority codec to put in MCF (along with MPC, Vorbis
and MPEG-audio). I just hope the association won't mean you discourage other
codec API and containers.

(remember I proposed to make an ACM for FLAC, due to limitations of ACM and
AVI/WAV, I thought it would be better to have first the container, second the
API (UCI is built for that, http://uci.sf.net/) and then the codec)

> 2. The core libraries would become BSD-licensed.  I've been really
> 50/50 on this ever since I submitted the question to Slashdot
> (see http://ask.slashdot.org/article.pl?sid=01/11/27/1650256 ).
> Now that WMA lossless is out it seems like less of an issue but
> I will still need to get permission from some of you, those that
> have contributed legally-significant (in the U.S. I think that
> means >10 lines of) code to libFLAC.  Only the codec libraries
> need to be BSD; the command-line tools and plugins would remain
> GPL.

Actually you'd better stay with the LGPL, or even GPL. And dual-license the code
to companies with the approval of other copyright holders. That could even help
get some money, support or whatever to work on FLAC, and you don't have much to
change.
 
> 3. Operations would move from Sourceforge to Xiph.  There are
> pluses and minuses, actually not so much minuses as unknowns.

As I said, CoreCodec is building an equivalent of SourceForge for multimedia
related projects. They (apparently) have the support of the FSF and don't seem
to be corporate oriented. But they are very young and still in alpha deployment,
that means no CVS :( (that's why MCF didn't switch yet)

My personal view on Xiph is that they make an audio codec (very good), a
container (good) and eventually a video codec (early). But becoming a host for
many other codec, applications, projects is something quite different. I just
hope Xiph can handle that.

Anyway, I feel like trolling, so I'll stop there. Emmett already knows the point
of view of the MCF people about this, as well as the CoreCodec ones.

The difference for the moment is that Xiph exists and works :)


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf