-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Non-Permissive License! #3121
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
Comments
I'm not a lawyer. Arduino's libraries are already under LGPL, and it's far less onerous than GPL. https://www.arduino.cc/en/main/FAQ That said, much of the IDF appears to be Apache 2.0. One would think if you're making a closed-source commercial product where this would matter, you'd probably be using the IDF as well as ensuring each and every piece of your code is in compliance with the license for the code it's using. That's not to say you can't do a lot with Arduino ESP32, but it's all about what you're linking with and through and I believe a lot of what's here in the shim between the Arduino side and the underlying IDF is closely related to the already-LGPL pure Arduino equivalents, so it only makes sense they'd license the Arduino ESP32 as LGPL just like Arduino is. The ethos (as best I understand it) is that if you have a Thing that uses LGPL, you need to release the LGPL source (including your changes) as well as your closed binaries such that someone could re-link the LGPL and those binaries and re-create the Thing. I'm not sure what "explicit documentation to support on the fly changes" is about.... if you change something that's LGPL you add the appropriate changelog entry to the file(s) affected. Unless you are planning to extensively modify the LGPL parts, it's hardly going to be onerous. Another point of reference: https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic |
I am developing embedded systems for the past 15 years in a major Silicon Valley company and much recently dealing with licenses and regulations on a regular basis. Arduino has proven itself to be the perfect prototyping platform, and a chip like ESP32 is a very good candidate for our proof of concept dev team, and probably to many others! Can somebody from ESP32 team share their reasoning behind choosing a non-permissive license and whether they think if this hinders the commercial applications for their chip? If you think dynamic linking is just as easy for hobbyists and startups, can you please provide a working example to link the libraries dynamically using Arduino IDE? ESP32 comes with fantastic examples using its unique features, such as the wireless interface and multi-core capabilities. There are also fantastic support libraries that provide the core functionalities. Anyone creating a copy of these examples and change them to their taste is subject to this non-permissive license. If you are statically linking and not disclosing you entire source code, you are breaching the LGPL license and your project is subject to legal terms! - This is the last thing we want to deal with in our company, especially when our goal is to develop with least friction as possible. Again, with the upcoming 1.0.3 version, I am suggesting to adopt Apache 2.0 license for Arduino-ESP32, just as it is the choice for ESP-IDF. It is the best open source license that all kinds of use cases and applications, while ensuring the openness of the platform. |
I don't think they can, as long as it references the Arduino libraries as stated in the previous response... that's the source of the LGPL license. Even if they changed the license, you're still required to adhere to the licensing requirements of the parent material. |
exactly :) LGPL comes from the Arduino above. I do feel your pain, but there is nothing we can do. |
Hi guys, have a Happy New Year all together. Sorry for warming up this discussion again, but this issue is more topical than ever because there are a lot of commercial products in the wild using ESP32 on Arduino development environment currently infringing the LGPL (resp. GPL). Relevant is, what's inside the binary. If you want to try the following sketch:
and compile it for a "ESP32 Dev Module" you can see at the output at linking, that at the end there is nothing else in the binary than code from the ESP32 package (maybe GCC runtime libs, but they are under GPL with GCC-exception and doesn't bring any license obligations). So it is not true, that there are requirements from parental material. Espressif can do whatever it wants to do with material they hold the rights for. And for sure they could relicense or dual license their stuff. By the way, to combine LGPL licensed code (which in this case with static linking will always fall back to GPL) with Apache-2.0 licensed code will not work, because of license incompatibilities. It makes no sense to license this ESP32-Arduino stuff under LGPL as long as there is no possibility for dynamically linking. Putting the firmware in a ESP32-based product will always result in a "Binary delivery Of Linked work With Header files Of Library Included In Linked work" and therefore licensed under GPL (not LGPL anymore!) and that's where the copyleft effect comes into play. All the product creators have to undisclose their code. I don't think it was intended that way and it is not practiced in reality either, because everyone thinks they have no license obligations to fulfill because of the LGPL (far from it, take a look at this little summary of "LGPL-2.1-or-later" license obligations: https://www.osadl.org/fileadmin/checklists/unreflicenses/LGPL-2.1-or-later.txt). Please reconsider the licensing issue... Regards, Thorsten |
Hi @dl9sec,
This is indeed possible and has been considered. However, based on our analysis of the contributions, we would need to get approval from a lot of people.
I agree that it is technically possible to produce a binary using arduino-esp32 project which wouldn't contain any code originating from the original Arduino codebase. However I don't think this is a practical use case: most projects which are built based on Arduino will in fact use So even if the above mentioned effort of relicensing of ESP32-specific code would be completed, it would not benefit the majority of the use cases. Hence the "wontfix" decision here. (Edit: I forgot to mention this, but this is all said under the assumption that the original LGPL-licensed Arduino code wouldn't be relicensed by its copyright holders under a more permissive license.) |
Hi @igrr, ok, I understand the trade-off between effort/cost and benefit, but it still doesn't make sense from a license perspective, especially if the license obligations are then not actively enforced by anyone. Nonetheless, thanks for the explanation. Regards, Thorsten |
Just for clarification: Distributing object files satisfies the requirement of the LGPL to allow the user to relink with an updated version of the Arduino libraries even when the binary is statically linked. So I disagree with the statement that the LGPL does not make any sense in this case. It is inconvenient, yes - but it is still useful to the end-user. |
The topic is now well known by us. We also provided a reasoning why this is not a direct engagement, but to summarize, this is no simple task and will compete for resources with all other endeavors in this project. For the foreseeable future, the license will remains as it is. |
LGPL is a fantastic license for open-source software applications, but when it comes to embedded development with statically linked libraries, it is quite a restrictive one.
It requires disclosing entire source code, or having clear separation between the source code and LGPL library components with explicit documentation to support on the fly changes, which is a support nightmare for commercial hobbyists and startups.
Please consider replacing the license with Apache 2.0, the same license ESP-IDF ships with, to be more inclusive to the community and all of the use cases.
The text was updated successfully, but these errors were encountered: