Review license usage
egpbos opened this issue · 16 comments
Look into which license xtensor-fftw is exactly supposed/allowed to use for what (code, conda package), given that FFTW3 itself is under GPL.
Quote from FFTW's site.
Non-free licenses may also be purchased from MIT, for users who do not want their programs protected by the GPL.
Could xtensor-fftw be double-licenced as both GPL and MIT? Also creating a LGPL header to wrap around FFTW may also be an solution.
I have since taken this approach for Barcode, which is in a similar situation:
The original contributions made as part of this code are distributed under the MIT license (see LICENSE file).
When compiled, this code must link to FFTW 3 and the GNU Scientific Library (GSL). FFTW is distributed under the GNU Public License v2 or a later version, GSL under GPL v3. This means that any redistribution of Barcode in binary form is subject to GPL v3 terms.
I'm not yet sure whether this is the best way to go, but I also don't want to lock my code into GPL, because I may to some point want to also include different FFT engines, preferably permissively licensed ones so that xtensor-fft(w) can also be used and redistributed permissively, if there's need for that.
And then there's also FFTW's option B of buying a commercial license, which would allow a company to use xtensor-fftw + FFTW without GPL.
I think this way we could avoid double-licensing. But as mentioned, I'm not completely sure, and open to more input/discussion.
Relevant discussion here: pyFFTW/pyFFTW/issues/229
Thanks @ashwinvis! I agree with @mreineck's interpretation. The point you make there I also agree with, LGPL for FFTW would have made things easier, but unfortunately that's not the case.
What do you think about the way I put it for Barcode (see my earlier comment above)?
I feel this is a tricky territory. It is good that you are not distributing any binary, but that is the ambiguity right. It would have been fine, if you just had codes like this:
#include <fftw.h>and rest are completely your own creation, not even derivative work. But you do have snippets of initialization of fftw function call in files like https://github.com/egpbos/xtensor-fftw/blob/master/include/xtensor-fftw/basic.hpp . Those do classify as derivative work don't they?
Those do classify as derivative work don't they?
That's a good and crucial question. Are there any sources on this?
Not a legal advice, but enjoy: https://cicero.xyz/v2/remark/github/coderefinery/software-licensing/master/talk.md/#23
Not legal advice either, but I do consider this presentation quite misleading. The statements it makes concerning GPL only hold if the "menu" is equivalent to "binary holding all compiled components". If we assume that "menu" means "all of the source code", then the statements regarding "virality" are incorrect.
The analogy to a restaurant menu is not really fortunate, I'd say, because there are no "source" and "binary" incarnations of a menu, and the distinction between the two is quite crucial.
I am not the author of the presentation, but
- source = recipe
- binary = cake
In that case I'm convinced that slide 27 of the presentation is incorrect. How is the license for the salad recipe dependent on the license of the cake recipe? Just because they are served in the same restaurant? That's definitely not how the GPL works.
BTW, the analogy has another problem:
- recipe <=> source
- cake <=> output of the binary, not the binary itself
This makes things look very different.
Yeah that is incorrect I agree with you. I think the point that they are making is since menu is a library linking the GPL cake, menu has to be GPL. But menu is the one which is linking the salad not the other way round. So salad can stay BSD or some other permissive license.
Exactly, the entire thing (menu) is "infected" with GPL. You could still distribute salad (and its recipe) separately under a different license. I'm now confused as to what role in this analogy xtensor-fftw would play
I think the whole analogy is bad, since, as I pointed out, the concept of "binary" has no tangible correspondence in the restaurant example.
The crucial question is most likely whether basic.hpp contains code that was copied from FFTW sources. If yes, then this code is still covered by GPL, and you can't put a BSD license on it. If there is no FFTW code in there and you only call FFTW, you can distribute this under BSD terms.
I think you can rely on the clarification in https://github.com/JuliaMath/FFTW.jl#license, which is MIT licensed. This is the safest interpretation since one of the authors of FFTW is involved in that project.
PyFFTW has now solved the issue by adding a custom LICENSE file, see pyFFTW/pyFFTW#229 (comment).