Re: [Kaldi-developers] Reason to not to use fftw

[Alexander S. <aso...@gm...>]

Thank you guys for such a lot of information!

On Tue, Jan 20, 2015 at 12:47 AM, Blaise Potard <bp...@id...> wrote:

> TL; DR: FFTW (GPL) is a pain to integrate to BSD / Apache code. Use FFTS?
>
> To expand upon Matthew's answer, FFTW is released under the GPL (not
> LGPL), so according to GNU
> (http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL):
>
>   "If a library is released under the GPL, it means that any software
> which uses it has to be under the GPL or a GPL-compatible license."
>
> While LGPL code is quite easy to integrate in other projects, GPL is
> definitely tricky if your code is not GPL. To summarise:
>   - if you want to use the GPL code in your project, you need to make
> sure your project uses a license compatible with the GPL,
>   - if you want to distribute a compiled version of your project in a
> license other than GPL, you need to make sure the dependency to the GPL
> code is not mandatory.
>
> That does not really mean it is impossible to use it in kaldi, it just
> mean you would have to be extra careful on how you do the binding with
> FFTW. Arguably, all source files that have direct references to FFTW
> would have to be released as GPL, but that's ok, you could just write a
> wrapper (released as GPL), with a header (released as Apache). Provided
> the rest of the source files use a license compatible with the GPL -
> which the license used by kaldi fortunately is, cf.
> http://www.apache.org/licenses/GPL-compatibility.html - it is not too
> big of a problem. However any version of kaldi compiled with support for
> FFTW would be automatically GPL.
>
> If FFTW was a mandatory dependency of Kaldi, the main issue would arise
> when distributing a compiled version of the code; you would then have to
> distribute it as GPL, and therefore provide all the sources, even the
> changes you would have liked to keep for yourself. Which is a hassle,
> most likely not commercially viable, and severely impacts kaldi's
> distributability.
>
> So if you want to be able to distribute kaldi (or its derivatives)
> commercially, you really need to make sure linking to fftw is optional,
> i.e. make sure kaldi can use other fft libraries. Which implies you
> would need to write a FFT wrapper class, with a header in the normal
> kaldi license, and a separate implementation for each of the FFT
> libraries to support - the one for FFTW would have to be GPL-licensed, etc.
>
> Making this effort could make sense if the FFT was one of the most
> time-consuming component of kaldi, but as far as I am aware, it is only
> used for feature extraction, which is not really one of the most
> time-consuming component.
>
> For HTK, it don't think it would be possible to use FFTW with the
> current HTK license, unless Microsoft bought a license for a commercial
> FFTW inclusion.
>
> For Sphinx, they probably could do the same as for kaldi, but for the
> same reason as above, it does not really make sense to make this effort,
> especially since almost no distributed version would want to use it.
>
> This being said, I would say including FFTS
> (https://github.com/anthonix/ffts) - which has a BSD license - could
> make sense, especially since it appears to be even faster than FFTW:
> http://www.cs.waikato.ac.nz/~ihw/papers/13-AMB-IHW-MJC-FastFourier.pdf
>
> Blaise
>
> On 19/01/15 11:19, Matthew Aylett wrote:
> > Licensing constraints make it impossible to use fftw in apache style/bsd
> > style software.
> >
> > Best
> >
> > Matthew
> >
> >
> > On Mon, Jan 19, 2015 at 9:22 AM, Alexander Solovets <aso...@gm...
> > <mailto:aso...@gm...>> wrote:
> >
> >     Hi,
> >
> >     I recently came across the fact that Kaldi, Sphinx and HTK have
> >     their own FFT implementation rather instead of using fftw library.
> >     Is there a strong reason for that in general case as well as for
> >     Kaldi in particular?
> >
> >     Thanks!
> >
> >     --
> >     Sincerely, Alexander
> >
> >
>  ------------------------------------------------------------------------------
> >     New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> >     GigeNET is offering a free month of service with a new server in
> >     Ashburn.
> >     Choose from 2 high performing configs, both with 100TB of bandwidth.
> >     Higher redundancy.Lower latency.Increased capacity.Completely
> compliant.
> >     http://p.sf.net/sfu/gigenet
> >     _______________________________________________
> >     Kaldi-developers mailing list
> >     Kal...@li...
> >     <mailto:Kal...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/kaldi-developers
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> > GigeNET is offering a free month of service with a new server in Ashburn.
> > Choose from 2 high performing configs, both with 100TB of bandwidth.
> > Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> > http://p.sf.net/sfu/gigenet
> >
> >
> >
> > _______________________________________________
> > Kaldi-developers mailing list
> > Kal...@li...
> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
> >
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>



-- 
Sincerely, Alexander