License about pygalmesh HOT 20 CLOSED

That is the end product is GPL-3+ and not MIT.

CGAL has its licenses, pygalmesh is MIT. What do you mean by "end product"?

from pygalmesh.

AFAIU, your code is using CGAL so it is affected by the virality of the GPL license.

from pygalmesh.

I don't think so. I don't distribute CGAL, neither its sources nor in binary form, so I believe it's all fine. The end user has to install CGAL and make sure to comply to its license (as well as pygalmesh's). It'd be different if I shipped a binary with CGAL included or something like that. Let me know if you disagree.

That being said, it might make sense to relicense pygalmesh as GPL-3+.

from pygalmesh.

According to this, I think I'm right.

from pygalmesh.

Thanks for the link. It says there:

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?
[...]
The software modules that link with the library may be under various GPL compatible licenses,

And indeed, MIT is compatible with GPL.

from pygalmesh.

From your link: "MIT licensed software can be re-licensed as GPL software, and integrated with other GPL software, but not the other way around."

from pygalmesh.

So anyone may release a toolbox with pygalmesh and CGAL included, the whole thing may be released under the GPL. (Because MIT doesn't take anything away from the GPL, e.g., it doesn't impose restrictions on how you distribute the sources.) That toolbox could not be relicensed under the MIT because that would give the user too much freedom, e.g., she would be allowed to hold back the source code (which contradicts the GPL).

from pygalmesh.

As soon as you compile pygalmesh you have something GPL. Which is what you get with pip, thus my remark on MIT being misleading. Maybe @lrineau can explain better than me.
@nschloe I hope you don't take this issue as an "attack", I just want to make thinks clear (I also opened a PR to re-license the CGAL bindings to avoid this kind of confusion).

from pygalmesh.

As soon as you compile pygalmesh you have something GPL.

And what exactly would that "something" be? There is no big binary that contains both CGAL and pygalmesh, just two libraries, one of which uses the other. If you were to create such a binary somehow, I agree that blob could only be distributed under the GPL (with source code included etc.). Also, pygalmesh does not work without CGAL, so all users will have to install CGAL first. If they do, they of course have to comply to its license, too.

I also opened a PR to re-license the CGAL bindings to avoid this kind of confusion).

Where?

from pygalmesh.

To use pygalmesh you have to compile a binary that contains parts of both and that's that binary that is loaded in python. I did not look at the detail of pygalmesh but I don't see how python would understand template code except if pygalmesh provides the compiled instantiations.

CGAL/cgal-swig-bindings#163

from pygalmesh.

To use pygalmesh you have to compile a binary that contains parts of both

No. There are two separate libraries, e.g., /usr/lib/x86_64-linux-gnu/libCGAL.so.13 and _pygalmesh.so. When running Python code, it dynamically links pygalmesh which in turn links libCGAL.

PS: pygalmesh does not use the SWIG bindings.

from pygalmesh.

CGAL is a template library, libCGAL.so is "empty" that why we even made it header only. call nm _pygalmesh.so | c++filt you'll see that it's full of instantiation of CGAL functions.

I know you are not using SWIG bindings but I mentioned it because you also somehow wrote a (much more user friendly) wrapper.

from pygalmesh.

CGAL is a template library, libCGAL.so is "empty" that why we even made it header only. call nm _pygalmesh.so | c++filt you'll see that it's full of instantiation of CGAL functions.

I think we're on the same page now. You're right: CGAL is a header library and hence the the _pygalmesh.so binary blob has to contain compiled CGAL code. That means you can distribute the blob only under the GPL. In fact, it doesn't really matter if CGAL was a compiled library. One would technically be allowed to ship the _pygalmesh.so closed-source, too, but it would be useless because it doesn't work without libCGAL.so.

What I don't quite understand yet is where you see confusion. To do anything with pygalmesh, you have to install CGAL. Obviously you have to comply to the CGAL license when doing so. Are you afraid that people compile _pygalmesh.so and say "Great, now I can distribute it under MIT!"?

from pygalmesh.

Great! More precisely a program using pygalmesh (especially because starting CGAL 5.0 there is no libCGAL.so by default). My main concern was that I read on the pip package page that the license is MIT with no mention of the license of CGAL (that is the dependency that have the more restrictive license). I don't really know how pip works and if you could get binaries. I think it would be less surprising to mention that CGAL is GPL and that the code using pygalmesh must comply with the terms of the GPL. On the SWIG binding page we put "This project is distributed under the Boost Software License, Version 1.0. Note that you need to comply with the license of CGAL for any usage of the bindings".

from pygalmesh.

My main concern was that I read on the pip package page that the license is MIT with no mention of the license of CGAL (that is the dependency that have the more restrictive license).

Well, CGAL is not the only dependency.:

• Eigen is published under MPL-2.
• pybind11 is under BSD-3
• numpy BSD-3 as well
• meshio MIT
• the Python standard library has PSF
• ...

All of those share some aspects ("open source"), but pose different conditions on how you can redistribute the code, for example. Then it goes further: What licenses do the dependencies of those dependencies have? How about h5py, one which meshio depends? Is boost somewhere in there?

In my view, it's not pygalmesh's responsibility to list the licensing conditions of all its dependencies.

from pygalmesh.

In my view, it's not pygalmesh's responsibility to list the licensing conditions of all its dependencies.

I think you might get inspired by other projects such as libigl.

Sebastien's goal is that your users are on the safe side and know that your wrapper+CGAL are GPL-ish and not MIT-ish as one might get the impression. And the above mentioned BSD-like licenses are not as critical as the GPL.

from pygalmesh.

Sebastien's goal is that your users are on the safe side

I'm really unhappy about this sentence. Judging from your GitHub profile, you're working for CGAL; @sloriot, too. Both of you should have disclosed that information up front. With this knowledge, the sentence sounds like a threat.

In the interest of putting this to bed, I'll link CGAL's license in the license section of the README. PR is #65.

from pygalmesh.

My opinion is that Nico is right that the license of the source code can be MIT. But I think that the license declared in the metadata of the Python module should be GPLv3 or GPLv3+. Because, once the Python module is compile from the sources of pygalmesh, the result is something that can only be used under the terms of the GPLv3+.

Once pygalmesh is installed (either from pip) or from another source, then pip show pygalmesh shows a line that says:

License: License :: OSI Approved :: MIT License

and that is at best misleading for users of the Python module.

from pygalmesh.

I think pip show pygalmesh does the right thing in that it correctly shows pygalmesh's license.

If you were able to compile pygalmesh, you must have already downloaded and installed CGAL. The license violation -- if any -- happens there.

I'll see if I can find a forum of sorts to post the question there. I'll post a link.

Edit: https://opensource.stackexchange.com/questions/9417/mit-code-interfacing-gpl3-library

from pygalmesh.

So, as contemplated before, I've relicensed pygalmesh to GPLv3+. This should calm everyone's concerns.

from pygalmesh.