IoT gadgets often only offer interfaces that do not allow inspecting or modifying their software. YOCTO tries to build specific software for IOT gadgets. And the GPLv3 requires that GPLv3-licensed software must be replaceable. Thus, YOCTO, IOT, and the GPLv3 are in a clinch, if YOCTO wants to be a distribution for IOT devices that do not come with an update interface. And we might ask, how YOCTO deals with this contradiction?
The “open source collaboration project” YOCTO promotes itself with the slogan “it’s not an embedded Linux distribution, it creates a custom one for you” (→ ): You collect and compile exactly what software you need. And therefore, you can also keep your IOT hardware simple. That’s the YOCTO-Idea. But sometimes, the structure of the hardware influences the satisfiability of the license requirements. And that could become thorny:
In general, YOCTO knows the complexity of FOSS compliance and already supports the product owners during the compilation process. For example, it lists all packages and all the respective licenses (→ , 3.5). Moreover, it allows the integration of the license texts into the image (→ , 5.20.2). And finally, it collects the corresponding code of the image for distributing it together with the product (→ , 5.20.1). These are important previous achievements for generating compliant images. [For being complete: these steps are necessary, but not sufficient. But that’s not our topic today.]
But the AGPLv3, the GPLv3, and the LGPLv3 require more. They postulate that the recipient of the software — the recipient of the IOT gadget — must be able to replace the running instance by an improved (or worsened) version, he himself has compiled (→ [1,2,3] §3): He must be able to install it on the hardware. If the IoT-gadget gives him access to its filesystem by any interface, everything is fine: he can save his version on the gadget, bend the corresponding link and restart the system. Bingo. But what, if the IoT-gadget does not offer such an interface? Or what, if the product owner does not want to allow such a replacement for respecting legal security reasons or for minimizing his efforts to maintain his customers?
Then — the answer is very clear — the product owner must not distribute any (A|L)GPLv3 licensed software as part of his product! Either one fulfills the conditions of the (A|L)GPLv3-licenses or one does not use software distributed under the terms of these licenses. There is no middle course.!
Luckily, YOCTO supports the developer on that score: It offers the opportunity to declare a variable INCOMPATIBLE_LICENSE as part of the recipe to create an image (→  Chapter 10). If — later on — the compilation process meets software licensed under licenses excluded by this method, then the process stops. Hereby, we can enforce to create images without (A|L)GPLv3 licensed software. But then — as, the YOCTO handouts clearly state — YOCTO can create functionally restricted images (→  pars pro toto: Chapter 10) simply due to the fact that much software is licensed under the GPLv3 so that it is excluded by this technique.
So far, so good. But there exists a core problem that affects the developer more deeply:
Some standard libraries — like for example the libstdc++ — are licensed under the GPLv3. If any, it is not easy to ignore or replace them. And indeed, YOCTO does not exclude them even if the YOCTO user has decleared GPLv3 as an INCOMPATIBLE_LICENSE. Hence, one might now ask whether YOCTO furtively generates non-compliant images. If one analyzes the situation more precisely, one will see, that YOCTO is nevertheless on the right way:
Standard libraries offer the techniques to process a program and by which it talks to the kernel. They are necessary. Ultimately, programmers cannot prevent using any standard library. And if such a standard library is licensed under a copyleft license, it directly follows from that, that all ‘higher’ programs or libraries using that standard library have also to be licensed under the same copyleft license. The “GNU Standard C++ Library v3” is such a standard library. It describes itself as an “ongoing project to implement the ISO 14882” (→  1.1) and as part of “GNU compiler collection” licensed under the GPLv3 (→  1.2) .
Nevertheless, the libstdc++ FAQ denies whether “[…] any program which uses libstdc++ falls under the GPL” very clearly. It answers: “No. The special exception permits the use of the library in proprietary applications.” (→  2.2)
How does this work?
The copyright owners of the libstdc++ have expanded the meaning of the license by adding a clause: “The source code is distributed under the GNU General Public License version 3, with the addition under section 7 of an exception described in the “GCC Runtime Library Exception, version 3.1” as follows”. (→ )
And this additional GCC Runtime Library Exception states under §1:
You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules. (→  §1)
On first glance, this is a hard-going sentence. But if we replace the weird terms by the meaning defined §0 of the libstdc++ runtime exception, we can easily understand the sentence:
The ‘Target Code’ refers to any “[…] output from any compiler for a real or virtual target processor architecture, in executable form or suitable for input to an assembler, loader, linker and/or execution phase.” The Runtime Library is the libstdc++ itself. And the ‘Independent Modules’ are the compiled versions of those files which need the libstdc++ for being executed. (→ )
Hence the first of the quoted sentences permits you to distribute your compiled program which needs the libstdc++ for being executed even if you violated the GPLv3 by distributing it — provided that your compiled program is generated by an “Eligible Compilation Processes”.
A compilation process is defined as that process which “[…] transforms code entirely represented in non-intermediate languages designed for human-written code, and/or in Java Virtual Machine byte code, into Target Code”. And such a compilation process “[…] is “ ‘Eligible’ if it is done using GCC, alone or with other GPL-compatible software, or if it is done without using any work based on GCC”. (→ )
So, the literal meaning of the first sentence of §1 of the libstdc++ Runtime Exception is, that you may propagate/distribute your compiled C++ programs requiring the libstdc++ even if you violated the GPLv3 conditions by that distribution as long as you have compiled all your c++ programs and libraries by the GCC (or none of them). By
But in our case of IoT gadgets, that’s not all. The question is, whether we really may distribute the libstdc++ itself by violating the license. To answer that question, we need the second sentence of §1:
It says that we may convey = propagate = distribute “[…] such a combination under terms of your choice, consistent with the licensing of the Independent Modules”. (→  §1) And the combination can nothing else than the combination of our independent modules, our programs, AND the libstdc++.
Bingo! Really? No!! In the case of copyright questions, it is, unfortunately, not sufficient having understood the literal meaning of a license. One must also prove, that the copyright owners use the same interpretation. The intended meaning is more important than the literal meaning of words. But in our case, it is not difficult to do so:
The copyright owner of the GNU compiler collection is the FSF. And as the copyright owner, the FSF also offers a libstdc++-FAQ where it explains its own understanding of the GCC RUNTIME LIBRARY EXCEPTION in the context of the libstdc++ (→ 
On the one hand, the FSF asks whether “[…] any program which uses libstdc++ falls under the GPL?”. And it answers, “No. The special exception permits the use of the library in proprietary applications.” (→  2.1) On the other hand, the FSF clearly states in the FAQ, that the libstdc++ cannot be replaced as simple as other libraries might be, because “much of the library consists of inline functions and templates, which are expanded inside the code that uses the library” and replacing the library would also require to recompiling the using program. (→  2.3)
Hence, even from the libstdc++ — FAQ, we can conclude, that FSF suspends (a) the strong copyleft effect and (b) the requirement to distribute libstdc++ only in an
Unfortunately, there is a third document, which seems to object to this understanding. The libstdc++ is not the only library distributed under the terms of the GCC runtime library exception. Therefore, the FSF also publishes a general “GCC Runtime Library Exception Rationale and FAQ”. (→ ) This document firstly explains why they now introduce such a general technique of exceptions. The second section explains how the exception works, which ends the meanwhile known statement: “As long as you use an Eligible Compilation Process, then you have permission to take the Target Code that GCC generates and propagate it ‘under terms of your choice.”
This third document does not clearly address the topic of whether we may distribute the libstdc++ itself under the terms of the runtime-exception. In the context of a question concerning the use of a completely proprietary compiler toolchain it suspends the copyleft effect. And it states that we must distribute the library itself by respecting the GPLv3. But note: This is an answer in the context of using a proprietary compiler toolchain. So, we may not automatically transfer it into the context of using the GCC compiler toolchain.
Why? Because in the case of the GCC compiler-based toolchain and the nature of a c++ library, the FSF would create a self-contradictory requirement: The suspension of the strong copyleft on the one side would not hold, if we — on the other side — must nevertheless publish our code using the library for fulfilling the condition, that the library must be replaceab
So, now it is clear: YOCTO may integrate the libstdc++ into any image even if the user has marked the GPLv3 as INCOMPATIBLE_LICENSE. The Runtime Library Exception of the GPLv3 suspends the strong copyleft effect, as well as the GPLv3 requirement to make the libstdc++ replaceable.
But that’s only valid for the libstdc++. You may not (automatically) transfer it to other standard libraries published under the GPLv3 with runtime exception. It depends on the nature of a c++-library as well as of the text of the libstdc++ runtime exception.
And in what way is this …
… part of the overarching topic FOSS Compliance? For fulfilling the requirements of FOSS licenses, we have to consider specific individual cases as well as side effects — for software, pictures, or documents. We should unhide trends and write guidelines. Above all, however, we must drive forward the automation of license fulfillment, make our licensing knowledge freely available, cast it into smaller tools, and bring it into larger systems: Because FOSS thrives on freedom through license fulfillment, large and small. That’s what also this article is about.
-  GPLv3 :- https://opensource.org/licenses/GPL‑3.0
-  AGPLv3 :- https://opensource.org/licenses/AGPL‑3.0
-  LGPLv3 :- https://opensource.org/licenses/LGPL‑3.0
-  libstdc++ licensing document containg the libstdc++ GCC RUNTIME LIBRARY EXCEPTION :- https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html
-  libstdc++ FAQ :- https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.license.any_program
-  General GCC Runtime Library Exception Rationale and FAQ :- https://www.gnu.org/licenses/gcc-exception‑3.1‑faq.en.html
-  YOCTO project page :- https://www.yoctoproject.org/
-  YOCTO project development manual :- https://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html
-  YOCTO project referenc manual :- https://www.yoctoproject.org/docs/1.9/ref-manual/ref-manual.html
- [A] YOCTO Howto :- https://wiki.yoctoproject.org/wiki/How_do_I