[Flac-dev] Should FLAC join Xiph?

[Drew Hess]

This is an issue I've been dealing with lately, too.  My employer is
releasing an image file format as open source, and I want to release it
under a license that both free and commercial software developers are
comfortable using.

I looked at TIFF and PNG, two examples of "free" image file formats that
have been widely adopted by both commercial and free software.  Both have
reference implementations released under very liberal BSD-ish licenses.  
TIFF has some incompatibility issues with vendor tags because it's such a
wide-open format, but most developers use the reference implementation,
libtiff.  And TIFF pre-dates the popularity of open source; times have
changed since libtiff was released.  PNG was developed more recently and
doesn't have any compatibility problems, as far as I know.

One case I can think of where a commercial vendor has taken a BSD-licensed
protocol and twisted it with proprietary changes is Microsoft+Kerberos,
but if I recall correctly, they eventually caved in to pressure and either
released their changes or made their implementation compatible with the
reference implementation.

Anyway, consider the chances that someone will use the BSD license to make
proprietary changes to FLAC.  Weigh that against the chances that FLAC
will be an even bigger success if you go with Xiph, and make your choice.

I think it's a no-brainer.  Go with Xiph!  It'd be a great addition to
Ogg.

Just be ready for lots more bug reports :)


-dwh-


On Thu, 21 Nov 2002, Steve Lhomme wrote:

> En réponse à earldunovant at earthlink.net:
> 
> > On 21 Nov 2002 at 1:39, Josh Coalson wrote:
> > 
> > > 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 ).
> > 
> > Interesting thead. I think your issues are with software developers. The
> > 
> > hardware guys are using the decoder, and they have no incentive to 
> > make do something bizarre that would make it incompatible with what 
> > the core encoder implementation outputs. But in thinking about the 
> > software end, I think back to the ARC vs. ZIP. If a particular 
> > implementation becomes very popular, the author would have plenty of 
> > incentive to develop extensions to the encoder that might break other 
> > people's decoder implementations. 
> > 
> > Are file extensions copyrightable? If they are, maybe you can copyright
> > 
> > the extension for FLAC files to insure that anything claiming to be a 
> > FLAC file is compatible with the core libraries. Incompatible extentions
> > must be called something else.
> 
> We actually have the same concern with the MCF format (see http://mcf.sf.net/).
> We want to make an open and standard file format for multimedia. And we
> definitely would like some hardware support in the future. But being open (the
> code as well) make any minor changes possible and so incompatible formats
> appearing, and claiming they are MCF.
> 
> To avoid that, the only solution we have found so far is to create a
> certification program and a logo. Only applications/hardware that pass a few
> tests on the standard would be allowed to use the logo.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flac-dev
>