IDF and ESPTOOL_PY Licence Clarification Request

[NevynSelby]

I am looking for clarification on the licence that is applicable to the ESP-IDF and the

So, the ESP-IDF states that the licence is Apache 2.0. The IDF includes the esptool_py which states that the tool is licenced under GNU (in the LICENCE file https://github.com/espressif/esp-idf/bl ... py/LICENSE).

The two seem to be at odds.

Background for this, it would be helpful to me if I could use part of the esptool_py which the Apache licence would allow but the GPL licence makes this ore difficult.

Regards,
Mark

[ESP_igrr]

Hi Mark,

The original source code in ESP-IDF repository is licensed under Apache 2, with a few exceptions (notably examples)
Since esptool.py is included as as submodule, we don't assume that the license of the IDF repository transfers to it. Its GPL license is mentioned on the following page: https://docs.espressif.com/projects/esp ... RIGHT.html
As you say, normally including GPL code into an Apache licensed application would not be possible. However since esptool.py does not become part of the application produced with IDF, we assume that it doesn't affect licensing of the application. Much like the fact that GCC is GPL licensed doesn't affect the licensing of the application built with GCC. In near future we plan to remove esptool submodule and instead will install esptool using pip, to avoid any possible confusion.

Which part of esptool.py are you interested in using? If this part was developed by Espressif, it may be possible for us to release it under a permissive license.

[NevynSelby]

We are looking at developing a method of programming the ESP32 from another microcontroller (STM32) using a C application which runs on the STM32. The basic flow would be:

• C# app on PC / Mac / Linux reads a binary image and send down serial line to STM32

• STM32 takes the image, validates it and then programs the ESP32 with the image

We have worked out from the serial comms documentation how to talk to the ESP32 and we can verify the chip ID etc.

The next step is to program the ESP32 from the STM32. The ESPTOOL has a binary image (ESP32 stub code) embedded in the Python script which the developer here now needs to send to the ESP32 to start the programming process.

We noted that the source code for the stub appears in the ESPTOOL repository. If we compiled this and used the resultant binary what would the licence be for use of the binary?

Regards,
Mark

[ESP_igrr]

Hi Mark,
The stub was initially developed by Cesanta and GPL licensed by them, so indeed we can't relicense that.

We are currently working on an embeddable C version of esptool, primarily to allow other host MCUs to flash an ESP chip. This is not quite ready for a public release (missing examples and such), but if it helps, I can share the early version with you. It doesn't utilize the stub (for the same reason you found) and therefore doesn't support compression, so upload times will be longer than those with esptool.py.

[NevynSelby]

Yes, I would appreciate seeing the early version of the flashing code. We'd be happy to provide feedback.

I will message you my contact details.

Thanks you for the offer,
Mark

[NevynSelby]

can share the early version with you. It doesn't utilize the stub (for the same reason you found) and therefore doesn't support compression, so upload times will be longer than those with esptool.py.

ESP_igrr,

Did you get my contact details? I think I have DM'd them to you.

Regards,
Mark

[Andrzej]

Hello Dear Friends from Espressif,

Allowing to upload (flash, like from esptool.py) ESP32 (and maybe even ESP8266 as well) from other host MCUs like STM32 by software written in C or C++ (a template / example project for that) would bring a value.

It may have sense to share what you have on it already (even marking it with Work In Progress status) through some github etc, as even a limited functionality may suffice for basic use cases.

Please do not to hesitate to share a link into the alfa of beta variants .

Alternatively: does anybody know about any ongoing effort for that elsewhere?

Thanks in advance,
Andrzej

[ESP_Angus]

Hi Andrzej,

Actually the release is done: https://github.com/espressif/esp-serial-flasher

Sorry, I know we updated a few threads when this was available but it seems we missed this one.


Angus

[Andrzej]

Hello Angus,

thank you for sharing the link!

I went throught the esp-serial-flasher project sources and following came into my mind:

1. is it using "a protocol" (SLIP_send_delimiter()/SLIP_send() functions) which is compatible with the one used in existing esptool.py (so it has also a chance to work with existing bootloaders comming asa a part of a factory ESP images, so no initial re-flashing of the bootloader is needed), or it introduces new "uploader" protocol/client to be run on target ESP board side ?

2. Readme file on github says about porting options (great!), so it give us an extendability into STM32 (of the uploader portion). I mean: ESP->ESP may just not be the most popular configuration for this type of functionaity, while STM32->ESP32 might be one of such.The project is cmake-based while STM32 Cube IDE likes makefile based projects more , but everything is doable... Just would need need to check 1. first.

?

Andrzej

[ESP_Angus]

1. is it using "a protocol" (SLIP_send_delimiter()/SLIP_send() functions) which is compatible with the one used in existing esptool.py (so it has also a chance to work with existing bootloaders comming asa a part of a factory ESP images, so no initial re-flashing of the bootloader is needed), or it introduces new "uploader" protocol/client to be run on target ESP board side ?

The first one, it talks to the same ROM loader that esptool.py talks to. That bootloader is actually in the mask ROM of the ESP32, nothing at all needs to be in the flash.

2. Readme file on github says about porting options (great!), so it give us an extendability into STM32 (of the uploader portion). I mean: ESP->ESP may just not be the most popular configuration for this type of functionaity, while STM32->ESP32 might be one of such.The project is cmake-based while STM32 Cube IDE likes makefile based projects more , but everything is doable... Just would need need to check 1. first.

Sorry, I'm not sure what the question is. We provided ESP->ESP as a sample and because this is what we used for our own testing and validation. The idea is that the porting layer is thin and the build requirements are very simple, you can treat this as a couple of source and header files instead of as an "ESP-IDF component".

If you have any problems copying the source files into a project for another embedded systems framework and adding the port layer functions, please let us know.