En r?ponse ? earldunovant@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 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@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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flac-dev >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [To: flac-dev@lists.sourceforge.net, mcf-general@lists.sourceforge.net] On Thu, 21 Nov 2002, Drew Hess wrote:> 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.This is interesting. I've never though of using copyright to attempt to prevent embrace and extend ploys by commercial venders. But in the end, it seems futile. A big company like Microsoft has enough resources to reimplement libFLAC should they wish. Then they can embrace and extend without worry about copyright. So I would recommend a Public Domain ``license''. I really don't understand why that choice isn't more popular among developers. - -- Russell O'Connor <http://www.math.berkeley.edu/~roconnor/> ``[Law enforcement officials] suggested that the activists were stopped not because their names are on the list, but because their names resemble those of suspected criminals or terrorists.'' -- SFGate.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (SunOS) iQCVAwUBPd1ANE0+aO5oRkNZAQILpwP/e9b19hXt9DOX1P2yMsTPMf9hBw1Py3Yj bpWbszaahRIgCoNg89G5htjENxdE8Apl6b4ETM3S8e5UR8XCLwDQbbPXByLoaew8 r0skUW8HBZQPbzj1pQExBl/DQ+gqA2JeLp8mIZisvdHJVT5Rbn7anUrCV6tlbdWw 0Zb7reLQhMk=bIQ+ -----END PGP SIGNATURE-----
This is why trademarks exists. You can release the source code under a BSD-style license, and license the Trademark only to hardware/software that passes a conformance test. The downside is that you are required to protect the trademark. As soon as you knowingly let someone slide, it's void. With anything like this, you really do need to get advice from a qualified attorney. -- =======================================================================Ian Pilcher pilchman@attbi.com ========================================================================
Drew Hess wrote:> Anyway, consider the chances that someone will use the BSD license to make > proprietary changes to FLAC. Weigh that against the chances that FLACWell, I think going GPL would be too much, only GPL softwares could use the library. BSD is too much too because changes in the software world (improvements, bugs, backdoors) would not be available to you. Only the hardware world is a problem. And usually when they support a format they're ready to pay for the development and even the port ot their architecture. I use a lot the SciTE editor which is BSD-like. Neil Hodgson is working full time on it because some company use his (BSDed) libraries in their closed software. And they pay the development for improvements or modifications. And that's not even in the hardware world ! I think for hardware, dual-licensing is the way to go. You can use a BSD license as the second license, but only available to people who pay (or any other reward, or nothing) for that version. Otherwise you can create your own one (maybe with the help of a lawyer). Just put that clearly in your webpage and sources. Noone will be scared of your code anymore :) A notice like : "Versions of this code are available under another license on demand".> 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 :)What keeps people around Xiph from using FLAC in OGG already and report bugs ? If marketing is what you're looking for it's OK. But that would be bad to consider people around Xiph so close minded that they would use your codec only if you are part of Xiph... *grin*