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

--- Steve Lhomme <[email protected]> wrote:
> En réponse à Josh Coalson <[email protected]>:
> > 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".

Hmm, that's the first I've heard of it.  I checked corecodec.com
but the FAQ is empty and I couldn't find an 'about' or 'mission'
or anything.  How new is it?

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

No, not at all.  The FLAC format is not tied to any particular
container.  It just happens that I have already done an Ogg
container.  The raw stream format can go in anything, and
native FLAC will continue to exist.  I won't discriminate
against other containers just because it's part of Xiph.  And
I still plan to keep the native FLAC codec layer separate
from the Ogg FLAC layer.

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

The thing is, I am finding out the same way as the Vorbis
guys that to get hardware support it is real hard to do it
with even LGPL.  All the hardware that supports FLAC right
now is running Linux and linking via shared lib, so LGPL is
OK, but anywhere else, LGPL is a roadblock.  I've gotten
pretty close with some big companies to FLAC support and it
fell apart on that.  Unless you are Microsoft/Dolby/Fraunhoffer
the marketing people don't even want to bother with licensing.

Josh


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


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