GPL License Compliance Request

[pfalcon]

ATT: Espressif Systems, 456 Bi Bo Road Suite A201 Pudong Zhangjiang Shanghai

Dear Sirs,

You provide a software product, "esp_iot_rtos_sdk" (hereafter - "the Product"), available via publicly accessible World-Wide Web URL https://github.com/espressif/esp_iot_rtos_sdk , licensed under the terms of GNU General Public License, version 3, as included in the Product and also available by the URL https://github.com/espressif/esp_iot_rtos_sdk/blob/master/LICENSE .

I obtained the Product in a legal way by the URL provided above, and found that it contains some binary-only components (see listing below). By the right given to me by GNU General Public License, version 3, I would like to request You to provide complete source code for the Product. Please kindly choose the same sources delivery method as you did for the Product - namely, providing them for download via publicly accessible URL. This will ensure your continued compliance with the license.

Following is the list of components which lack associated source code:

• lib/libmain.a
• lib/libnet80211.a
• lib/libphy.a
• lib/libpp.a
• lib/libwpa.a
• tools/genflashbinv6.exe
• tools/xxd.exe

Sincerely,
Paul Sokolovsky, on the behalf of Open Source community.

[pfalcon]

Ok, so while there is no direct reply still, I may imagine this commit: 9ee27f9 somehow related.

But please note that remove not open source libraries does not resolve the issue. GPL applies to the project as the whole, to all part required to make it run. So not providing source for components required to make project build and run is still violation of GPL.

Worse, if 3rd-party uses your SDK to build a product, they are in violation of GPL, because any customer by the right given by GPL may request source code of that product. But 3rd-party does not have that source - you, the vendor, never provided it. That means there's no legal way to use your SDK, and anyone using it does so in contradiction to license. That means that no decent 3rd-party vendor will use your modules - you do not allow to use them legally.

However sad it is to say that, the problem is in GPL - it is simply not suitable for your business model. Please kindly consider switching to more appropriate license for your SDK - for example, MIT or BSD. Those license are liberal and allow to have open- and closed-source components in one project, because they are not copyleft (do not virally apply to all project components). Also, MIT is the license of many open-source components you use yourselves - lwIP, axTLS, etc. So, it would be very wise and community-friendly to use that license for your entire SDK.

Thanks again.

+1

hi all,
we are sorry that we screwed up on GPL thing. We have had an extensive review on this matter. And we have decided we are not able to open source our MAC, and the low level drivers. There are many compelling reasons to not do this, including the possibility of building devices that violate the WiFi standards and wreak havoc on the network. We are passionate about open source and we wish to support the open source movement as much as we can.
To address this, we decide that perhaps it is better to move to GPLv2.
Would this do?
Thank you.
John Lee

[zarya]

GPLv2 will have exact the same issue as GPLv3 you need to make all the sources public.

[pfalcon]

@espressif: Thanks for your response!

we have decided we are not able to open source our MAC, and the low level drivers

That's perfectly understood. Many companies don't open up their IP (intellectual property) completely, and while there're reasons to do so, it's just the matter of fact that the industry as the whole is not yet there, so Espressif's position is understood.

To address this, we decide that perhaps it is better to move to GPLv2.

As already pointed out above, that won't solve the issue. The issue is that GPL licenses (both v2 and v3) are strict and copyleft licenses. That means if you say "SDK is licensed under GPL", then each component, every file in SDK is licensed under GPL, and GPL requires source code to be provided. Moreover, it requires that any 3rd-party project which forms fusion with GPL code (e.g. by means of static linking, and that's the only realistic choice for deeply embedded projects like ESP8266-based), to be also GPL licensed - again, full source of SDK and 3rd-party code must be provided.

All this means that GPL is advantageous for vendors who sell software - they for example can provide both commercial and open-source versions of software, and be sure that somebody else cannot hijack their source code, add a killer feature and sell it with direct competition to the original company - they can take code, add feature, and sell, but they also must provide source code, which can be further disseminated for free, i.e. there's no incentive to compete with the original company.

But GPL makes little sense for hardware vendors to license their own software under. That's because HW vendors are usually interested in selling as much as possible hardware. To do that, they need to make that hardware usable as easy as possible to their customers. And GPL puts additional burden on both original HW vendor, and most importantly, their customers, producers of hardware devices.

I don't know how it happened that after analysing the situation, you chose GPL. I may imagine that you took Linux as an example. But Linux is a different matter. It doesn't belong to anyone in particular, and there're hundreds of vendors who work on it. A lot of Linux value also comes from hardware-independent components, like file-systems, high-level networking, etc. Suppose server vendor1 decided that to sell their servers better, they need to implement super-duper filesystem. They implement it, but it's of course reuses part of existing Linux code written by other members. And GPL requires vendor1 to release source code of their filesystem, so other people can benefit from vendor1's work the same way as the vendor1 benefited from other people's previous work. And if vendor2 figures that they can take vendor1's work, add killer feature and sell even more servers - they can, but they must release source code for their killer feature, so that vendor1 (and everybody else) can benefit from it and their previous investment in the development, which enabled this killer feature. So, for Linux, very big project with many contributors, GPL is beneficial.

But it's quite different situation with ESP8266 SDK. It consists of existing generic open-source components (lwIP, axTLS, etc), and your low-level code for ESP8266. You don't need to protect "existing generic open-source components" part with GPL - if someone will want to take code of those projects, they will take them from projects themselves, and those projects are already liberally licensed (BSD or MIT). Then what's left is your low-level code. But it's specific for your product - unlikely someone will reuse it for another product (that probably will be more complicated than writing needed code from scratch). And you already protected your low level code. You so well protected it that it's not even compatible with GPL - you simply don't provide source code at all.

So, from the above, I hope it's pretty clear that there's no point for you to license core SDK under GPL. Liberal license like BSD or MIT is the better, and actually perfect, choice.

Thanks!

[bryanlyon]

I think it's important to mention here, that the copyright owner cannot be "out of compliance" with the GPL (any version). Since the GPL is a license to use their software it only places limits on the people who use it, requiring them to make changes public, it actually places no restrictions on the owners. Meaning they can easily state that part x is licensed under the GPL but part y is closed binary and they are not "violating" anything but the spirit of the GPL, the legal parts are all in compliance.

Now, if they use other people's code that is GPLed in with their own binary blobs that's a different problem but also not what we're talking about here.

[pfalcon]

I think it's important to mention here, that the copyright owner cannot be "out of compliance" with the GPL (any version).

Well, more exactly, an agent to enforce the license is copyright holder. That's why GNU software requires copyright assignment to FSF - to make it possible to actually protect users' rights. It's possible for copyright owner be "out of compliance" with license (how would you call it when owner violates license terms?), but such non-compliance is non-enforceable, yes.

they can easily state that part x is licensed under the GPL but part y is closed binary and they are not "violating" anything but the spirit of the GPL, the legal parts are all in compliance.

They can easily state, but if they don't and have single license - GPL, then it's all GPL. And even if they do, but someone else later combines parts under different licenses, they should be compatible (GPL prevails, and requires source code availability).

So, the main issue, as was explained before, is not copyright owner (Espressif), but other users. With the current situation, it's not possible to use the SDK and be in compliance with GPL, under terms of which the SDK was released - because if you make a product based on SDK (which has to be licensed under GPL, as GPL is copyleft license), anyone has right to request source code from you, and you cannot provide it, because you never had it in first place.

The solution to all this hurdle is simple - just switching to a liberal license like MIT or BSD.

[mkmik]

@pfalcon said:

it's possible for copyright owner be "out of compliance" with license (how would you call it when owner violates license terms?), but such non-compliance is non-enforceable, yes

I had the impression that @bryanlyon meant that you cannot violate GPL on your own code because you are not granting yourself a license to use your own code under the GPL, but instead you have an implicit license to use your own code anyway you like it, including choosing whom to give it and under which license terms. (things get more complicated when your GPL code is a derivative work, so let's just assume that you own the full component).

The distributor can violate the GPL license when shipping a binary and not providing all the sources necessary to build said binary. The author and distributor can be the same person, but with a different hat.

What happens if your distribution media contains both your GPL source code and some binary blobs that you also own and that are non-GPL ?
You are not violating any terms by creating and shipping such a distribution, but the end user has no means to know what she can do with it.

By default, linking against those binary blobs doesn't put the end user in violation of any license (provided that she obtained the binary blobs legally in the first place and that the headers are GPL compatible), but however the user is not allowed to distribute them further nor distribute derivate work in the form of binaries produced by linking against those blobs (because she would be bound to offer the full sources for the whole thing, including parts that she doesn't have). Note the user can run the program on premises but must avoid implicit distribution such as for example JavaScript code transferred for client side execution.

That said, it's a bad practice to put your end user in a position that she doesn't know what she can or can not do with your code.

Your license for your GPL code has to state that you allow linking against a specific non-GPL component. Or you can use a more permissive license in the first place if suitable.

In any case, your closed-source component has to state that it can be redistributed with terms that make it possible to ship, bundle or link it with your open source component.

See an example at https://mariadb.com/kb/en/mariadb/mariadb-license/

[bryanlyon]

I agree that it's bad form to provide an incomplete solution, but the GPL does not restrict the users from distribution. Then the only real requirement if they do provide binaries is that they include the SDK in it's closed form or a link to the closed SDK. This is allowed in much the same way that using header files for a closed library is allowed. The GPL only requires that you provide the source and all tools to compile it.

Specifically the section of the GPL that allows this is as follows (From section 1. Source Code) "The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. "

The binary blobs mentioned in the demands clearly fall under "System Libraries, or general-purpose tools" pretty clearly (though I'm not a lawyer and this is not legal advice, it's just a common interpretation of what it means) and therefore the GPL is perfectly acceptable, even for binary shipments.

System Libraries:
lib/libmain.a
lib/libnet80211.a
lib/libphy.a
lib/libpp.a
lib/libwpa.a
General Purpose Tools:
tools/genflashbinv6.exe
tools/xxd.exe

This is no different than shipping a computer with Linux along-side a closed-source-bios. Linux uses the "general purpose tools" of the bios. Or a GPL driver that includes (or relies on in other ways) a closed-source firmware. The GPL cannot force compliance on an unrelated party (or on the initial copyright owner) since they are not a licensee under the GPL and are not bound to it's terms.

However, this is all a moot point since they did change to the MIT license (New license since Feb 27 can be seen at https://github.com/espressif/esp_iot_rtos_sdk/blob/master/LICENSE )

[pfalcon]

Your license for your GPL code has to state that you allow linking against a specific non-GPL component.

GPL is itself a license. If you modify GPL, it is no longer GPL. You can have 2 licenses for your code, but if one of them is GPL, the release should abide by its terms, regardless of what another license say.

[pfalcon]

The binary blobs mentioned in the demands clearly fall under "System Libraries, or general-purpose tools"

And for me it's pretty clear that they do not, and comprise part of application environment. "System Libraries" is something a user unalienably and standardly has. For example, any Unix system has C standard library, so you don't need to provide source for that with your application. But in case of Espressif SDK, 90% of binary blobs is adhoc application libraries, not implementation of well-known general purpose library, moreover statically linked with GPL source code. Presenting it otherwise means letting anyone to take a GPL application, put all its code into a binary library and then have a "source" of int main() { do_stuff_from_library(); }, then ship these binaries and say that they comply with GPL because everything is "System Libraries". No, that's obvious violation. Back to ESP8266, what is system libraries for it is its mask ROM contents. I agree it's not a violation to not provide source for it.

However, this is all a moot point since they did change to the MIT license (New license since Feb 27 can be seen at https://github.com/espressif/esp_iot_rtos_sdk/blob/master/LICENSE )

Yes, that's in particular result of my correspondence with Espressif decision-makers. I don't close this ticket from my side, because I'm waiting when it will be propagated to standard SDK releases (which is unfortunately not distributed via github so I could not open ticket against it).

[bryanlyon]

Sorry, but the code you were asking for is literally a system library. That is what those lib files are. I agree that is not what GNU wanted to mean when they said "system library" but it doesn't change the fact that legally, those are system libraries and exempt.

And while what you said about "int main() { do_stuff_from_library(); }" may sound ridiculous, it is actually a very reasonable thing to do if you're open sourcing an example program to access a closed SDK, which is done on a daily basis by Google and other companies.

Also, in reference to your message to @mmikulicic the GPL does allow you to add additional "freedoms" to your license and it still be GPL. This comes from section 7 Additional Terms which says "'Additional permissions' are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law."

In other words, they can add any exceptions or additional licenses for other parts if they want, that includes exceptions from providing the code for linked parts in a binary. These are limited to adding additional permissions and prevents adding restrictions (except for certain things like Trademarks) but it would be perfectly reasonable for an exception to allow linking closed source libraries without making those available.

I appreciate the work that you are doing in improving the clarity of the license, but please do not try spouting opinions of how you believe things should be as facts for how things are.