Skip to content

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

Closed
JAntHarrison opened this issue Aug 21, 2019 · 9 comments
Closed

Non-Permissive License! #3121

JAntHarrison opened this issue Aug 21, 2019 · 9 comments
Labels
Resolution: Wontfix Arduino ESP32 team will not fix the issue Status: Blocked upstream 🛑 PR is waiting on upstream changes to be merged first Type: For reference Common questions & problems

Comments

@JAntHarrison
Copy link

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.

@MartyMacGyver
Copy link
Contributor

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

@JAntHarrison
Copy link
Author

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.

@kbickham
Copy link

kbickham commented Sep 21, 2019

I am suggesting to adopt Apache 2.0 license for Arduino-ESP32

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.

@me-no-dev
Copy link
Member

exactly :) LGPL comes from the Arduino above. I do feel your pain, but there is nothing we can do.

@dl9sec
Copy link

dl9sec commented Jan 4, 2023

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).
I absolutely agree withj @JAntHarrison and sorry @me-no-dev, there is absolutely nothing which has to do with LGPL coming from an "Arduino above".

Relevant is, what's inside the binary. If you want to try the following sketch:

void setup() {
  // put your setup code here, to run once:
}

void loop() {
  // put your main code here, to run repeatedly:
while (1);
}

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.
If they use copyrighted material from other right holders, they can ask for a relicensing/dual licensing. If all of them agree, no biggy.

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
(also not a lawyer, but busy most of the time of the professional working day with open source license compliance management)

@igrr
Copy link
Member

igrr commented Jan 4, 2023

Hi @dl9sec,

If they use copyrighted material from other right holders, they can ask for a relicensing/dual licensing. If all of them agree, no biggy.

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.

So it is not true, that there are requirements from parental material.
...
there is absolutely nothing which has to do with LGPL coming from an "Arduino above".
Relevant is, what's inside the binary. If you want to try the following sketch

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 String, Stream, HardwareSerial and other libraries derived from the original LGPL licensed Arduino code. Even the simplest use of Serial or WiFiClient brings the dependency on these fundamental libraries based on the original Arduino code.

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.)

@dl9sec
Copy link

dl9sec commented Jan 4, 2023

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.
The Espressif part can also be placed under a permissive license compatible with (L)GPL at any time.
Possibly the whole Arduino ecosystem was and is indeed only for open source professional products, but to be honest I'm afraid the Arduino guys just didn't understand the LGPL...

Nonetheless, thanks for the explanation.

Regards, Thorsten

@VojtechBartoska VojtechBartoska added Status: Blocked upstream 🛑 PR is waiting on upstream changes to be merged first and removed Status: Pending labels Feb 20, 2024
@everslick
Copy link
Contributor

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.

@rftafas rftafas added the Resolution: Wontfix Arduino ESP32 team will not fix the issue label Jan 6, 2025
@rftafas
Copy link
Collaborator

rftafas commented Jan 6, 2025

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.

@rftafas rftafas closed this as completed Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Wontfix Arduino ESP32 team will not fix the issue Status: Blocked upstream 🛑 PR is waiting on upstream changes to be merged first Type: For reference Common questions & problems
Projects
None yet
Development

No branches or pull requests

9 participants