8

I have a very specific question in this seemingly gray area.

There is a very popular MIT-licensed PyPI academic Python package calfem-python.

There is another very very popular GPLv2-or-later-licensed PyPI Python package gmsh.

calfem-python lists gmsh as a dependency in its build-package.py file.

Let's imagine a hypothetical commercial app built upon a closed-sourced Python package that has calfem-python (but not any of its source code directly) as it dependency in its setup.py file and calls at least one calfem-python class (calfem.mesh.GmshMeshGenerator) from calfem-python.mesh module that in its turn imports and uses gmsh.

That hypothetical closed-sourced Python package doesn't explicitly list gmsh at its dependency in its setup.py file.

Both MIT-licensed calfem-python and GPLv2-or-later-licensed gmsh are installed from PyPI after being triggered in chain by setup.py of that hypothetical closed-sourced Python package and by build-package.py of calfem-python, respectively, only at the time of the installation of that hypothetical closed-sourced Python package on a final user's machine.

What do you think about this situation and applicability of the GPLv2-or-later license to this distributed closed-sourced Python package with no code from calfem-python or gmsh included in its distribution?

To provide more context (a follow-up): After writing this question, I noticed that the source code of the calfem-python.mesh module has two options:

  1. A default hard-coded option (it cannot be switched with arguments when importing calfem-python, only re-hardcoded in a fork or by inserting its code into the new project) self.use_gmsh_module = True, which leads to using the imported gmsh Python package and its functionality.
  2. And re-hardcoded self.use_gmsh_module = False, which leads to finding (presumably separately installed) gmsh.exe in the file system and using its functionality via gmshExe = which("gmsh.exe") and output = subprocess.Popen(r'"%s" "%s" %s' % (gmshExe, geoFilePath, options), shell=True, stdout=subprocess.PIPE).stdout.read().

My assumption is that this 2nd option, if re-hardcoded, can allow using a separately installed gmsh.exe (this product is distributed not only as a Python package) at arm's length via subprocess.Popen() and subprocess.PIPE and not violate the GPLv2-or-later license.

I am very curious to hear your opinions on this 2nd option if the 1st option is not good for that hypothetical scenario?

Improve this question
2
  • 1
    Have you already tried to reach out to the maintainers of calfem-python with this question? What is their response? Commented Oct 17, 2024 at 8:02
  • @Martin_in_AUT A very good question. In fact, I haven't. I also thought how this might be possible for them to release their source under MIT, but then I realised that calfem-python didn't "distribute" their code, they just put it in the repository for reuse and if someone wants to use a portion of that code for whatever and potentially modify the whole code base removing that GPLv2-or-later dependency, they can do so and not inherit GPLv2-or-later. Commented Oct 17, 2024 at 11:45

1 Answer 1

Reset to default
7

The GPL license is quite clear in how its authors intend it to apply in such a situation: If any part of an application uses or depends on GPL-licensed code, then all parts of that application must be distributed under a GPL-compatible license and the work as a whole is subject to the terms and conditions of the GPL license.

This means that, by having an indirect dependency on GMSH, the closed-source package is violating the GMSH license.

Now, it has not yet been tested in court if the intentions of the authors actually hold up, especially in cases where the final executable is only assembled on the end-user's computer. But do you want to bet your business on finding out?

The second option you presented, of calling an external GPL-licensed executable and depending only on its documented command-line arguments and output is a way to keep your code and the GPL code as completely separate works as far as copyright is concerned. In that case, your code is not considered a derivative work of the GPL code and you are completely free in your license choice.

Improve this answer
3
  • @[Bart van Ingen Schenau], thank you so much for your detailed response. I dug deeper into the source code of calfem-python and found an interesting built-in option to re-hardcode it so that gmsh be used as a separately installed gmsh.exe binary (not a part of the python package). Probably this options makes this use scenario compliant... Commented Oct 17, 2024 at 14:43
  • 3
    @Alex, that would depend on how intricate the connection to gmsh.exe would be. Basically, how much knowledge of the inner workings is present in the Python code. Commented Oct 17, 2024 at 14:47
  • @[Bart van Ingen Schenau], yes, this is very reasonable. I can see in the source code that the interworking with gmsh.exe is limited to finding its location in the file system and this line of code output = subprocess.Popen(r'"%s" "%s" %s' % (gmshExe, geoFilePath, options), shell=True, stdout=subprocess.PIPE).stdout.read() Commented Oct 17, 2024 at 14:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.