Skip to content
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

Open
egpbos opened this issue Aug 5, 2018 · 16 comments
Open

Review license usage #36

egpbos opened this issue Aug 5, 2018 · 16 comments

Comments

@egpbos
Copy link
Member

egpbos commented Aug 5, 2018

Look into which license xtensor-fftw is exactly supposed/allowed to use for what (code, conda package), given that FFTW3 itself is under GPL.

@marty1885
Copy link
Contributor

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.

@egpbos
Copy link
Member Author

egpbos commented Nov 5, 2018

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.

@ashwinvis
Copy link

Relevant discussion here: pyFFTW/pyFFTW/issues/229

@egpbos
Copy link
Member Author

egpbos commented Nov 28, 2018

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)?

@ashwinvis
Copy link

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?

@egpbos
Copy link
Member Author

egpbos commented Nov 28, 2018

Those do classify as derivative work don't they?

That's a good and crucial question. Are there any sources on this?

@ashwinvis
Copy link

Not a legal advice, but enjoy: https://cicero.xyz/v2/remark/github/coderefinery/software-licensing/master/talk.md/#23

@mreineck
Copy link

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.

@ashwinvis
Copy link

I am not the author of the presentation, but

  • source = recipe
  • binary = cake

@mreineck
Copy link

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.

@ashwinvis
Copy link

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.

@egpbos
Copy link
Member Author

egpbos commented Nov 29, 2018

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 🤔

@mreineck
Copy link

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.

@ashwinvis
Copy link

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.

@ashwinvis
Copy link

cf: JuliaMath/FFTW.jl#41 (comment)

@egpbos
Copy link
Member Author

egpbos commented Mar 15, 2021

PyFFTW has now solved the issue by adding a custom LICENSE file, see pyFFTW/pyFFTW#229 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants