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

[Blaise P. <bp...@id...>]

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
>