-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review license usage #36
Comments
Quote from FFTW's site.
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:
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? |
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
|
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:
This makes things look very different. |
Yeah that is incorrect I agree with you. I think the point that they are making is since |
Exactly, the entire thing ( |
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 |
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). |
Look into which license xtensor-fftw is exactly supposed/allowed to use for what (code, conda package), given that FFTW3 itself is under GPL.
The text was updated successfully, but these errors were encountered: