Inclusion in non-GPL 2.0 licensed tools (ESPTOOL-244)

[moritz89]

Hi, I am aware of a number of tools that are licensed under the MIT or Apache 2.0 license or not at all that use this tool. AFAIK as soon as esptool is imported (subprocess.Popen circumvents this) the parent software falls under the GPL requirements.

• https://github.com/esphome/esphome
• https://github.com/m5stack/Core2-for-AWS-IoT-EduKit
• https://github.com/bwhitman/alles
• https://github.com/IoTReady/prepare_script_awsiot
• https://github.com/littleyoda/littleyoda-DCC-Decoder-Flasher-test

Are there any plans of recourse, in the sense that the requirements of the GPL will be enforced?

[projectgus]

Hi @moritz89,

Thanks for asking about this, it's an interesting question.

Hi, I am aware of a number of tools that are licensed under the MIT or Apache 2.0 license or not at all that use this tool.

I Am Not A Lawyer and this isn't an official position, but I've taken a look. I'm not sure I see a significant issue here:

• The distributions of esptool are in source form, or arguably not distributed at all in the case of requirements.txt (the end user is the one who runs pip and adds the GPLed source code to their local modules directory.)
• It's legally uncertain whether one project dynamically loading another at runtime (ie import esptool) actually creates a derivative work under copyright law (necessary for GPL to apply). A summary of the arguments can be found here. If the status of binary Linux kernel modules is uncertain then runtime Python loading must be even more uncertain. It seems unlikely that flashing scripts that import esptool are automatically creating derivative works of esptool. Many of them only call esptool.main(args), essentially the same level of integration as subprocess.run(), and it's possible to integrate at this level without reading any esptool source which seems to exclude the possibility of deriving a new work from the esptool source.
• Even if some of these projects were creating a derivative work, then the MIT and Apache 2.0 licenses are both GPL compatible (Apache 2.0 is GPLv3 compatible only but esptool is "GPLv2 or later"). So it's already possible to relicense most of these wrapper scripts as GPL or incorporate their code into another GPL project without any issues. (Repos with no license are a different matter, I think they should preferably have some kind of license!)

Please let me know if you think I'm missing something.

[moritz89]

AFAIK (gnu.org, SX 1, SX 2) as soon as code is imported into a process (.so for C++, import for python), it is considered dynamic linking which therefore causes the linking code to fall under the GPL license. This is the case for the examples I listed above.

As for the case of code licensed under the Apache 2.0 and MIT license, it only works in one direction. That is, the Apache 2.0 and MIT code may be included by GPL code, but one may not distribute code that includes a GPL library (as is the case here) under a permissive MIT or Apache 2.0 license.

As far as I can tell, your goal is to use the permissiveness provided by the LGPL which allows linking of copyleft code without forcing the code that links to it to be copyleft (It only has to provide a mechanism to relink the LGPL library).

[projectgus]

as soon as code is imported into a process (.so for C++, import for python), it is considered dynamic linking which therefore causes the linking code to fall under the GPL license. This is the case for the examples I listed above.

That is the FSF's position on this, but just because the FSF says this does not make it a legal fact. The "SX 1" reference you posted links to Lawrence Rosen's different interpretation, I linked to another one above. The Linux kernel policy on binary modules is probably the most widely used counter-interpretation.

As I understand it, the legal question relies on whether or not some code A that dynamically references another piece of code B creates a derivative work either at the time the author writes the code A or at the later time when an end user runs that code, and whether GPL distribution clauses apply to either of these. That's why the first reply discusses derivative works.

EDIT: Cleaned up as this reply as I over-stated it the first time.

As for the case of code licensed under the Apache 2.0 and MIT license, it only works in one direction. That is, the Apache 2.0 and MIT code may be included by GPL code, but one may not distribute code that includes a GPL library (as is the case here) under a permissive MIT or Apache 2.0 license.

Understood. My point is that having an MIT or Apache license doesn't stop someone from re-incorporating any of the additional scripts into their GPLed project. This is more of a practical concern of whether this script licensing is causing any problems for someone who wants to work with GPL code.

As far as I can tell, your goal is to use the permissiveness provided by the LGPL which allows linking of copyleft code without forcing the code that links to it to be copyleft (It only has to provide a mechanism to relink the LGPL library).

I agree that would be clearer, even though as mentioned above I don't think the current situation is necessarily a problem.

Espressif isn't the only copyright holder of esptool (other holders include the original author, myself as an individual from before I worked at Espressif, plus a lot more people). So any relicensing is not a straightforward thing to do.