← Kippa Solidarity in Germany | LilyPond, LilyPond Snippets and the GPL: About some bad side effects. →

YOCTO, IoT, and the GPLv3

IoT gadgets often only offer interfaces which do not allow to inspect or to modify their software. YOCTO tries to build specific software of IOT gadgets. And the GPLv3 requires that GPLv3 licensed software must be replaceable. So, 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” (→ [7]): 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 (→ [8], 3.5). Moreover, it allows integrating the license texts into the image (→ [8], 5.20.2). And finally, it collects the corresponding code of the image for distributing it together with the product (→ [8], 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 (→ [9] Chapter 10). If – later on – the compilation process meets software licensed under licenses excluded by this method, then the process stops. Hereby, YOCTO can be enforced to created images without (A|L)GPLv3 licensed software. But then – as, the YOCTO handouts clearly state – YOCTO can create functionally restricted images (→ [9] pars pro toto: Chapter 10) simply due to the fact that many software is licensed under the GPLv3 so that it is excluded by this technique.

So far, so good. But there exists a core problem which 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 to replace them. And indeed, YOCTO does not exclude them even if the GPLv3 is mentioned 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 methods by which a program is processed by the kernel and by which it talks to the kernel. They are necessary. Ultimately, programmers cannot prevent to use 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” (→ [5] 1.1) and as part of “GNU compiler collection” licensed under the GPLv3 (→ [5] 1.2) .

Nevertheless, the libstdc++ FAQ denies the question whether “[…] any program which uses libstdc++ falls under the GPL” very clearly. It answers: “No. The special exception permits use of the library in proprietary applications.” (→ [5] 2.2)

How does this work?

The meaning of the license is expanded by a method, the license itself offers. As it is said in the libstdc++ license, “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”. (→ [4])

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. (→ [4] §1)

On first glance, this is a hard-going sentence. But if one replaces the weird terms by the meaning defined §0 of the libstdc++ runtime exception, the sentence can easily be understood:

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. (→ [4])

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”. (→ [4])

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 this you circumvent the strong copyleft effect.

But in our case of IoT-gadgets, that’s not all. The question is, whether we are also allowed to 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”. (→ [4] §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++ (→ [5]) . And in this FAQ, you can find this:

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 use of the library in proprietary applications.” (→ [5] 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. (→ [5] 2.3)

Hence, even from the libstdc++ – FAQ, we can conclude, that FSF suspends (a) the strong copyleft effect and (b) the requirement, that the libstdc++ must be distributed in an envrionment, which allows to replace it.

Unfortunately, there is a third document, which seems to object to this understanding. The libstdc++ is not the only library which is distributed under the terms of the GCC runtime library exception. Therefore, the FSF also publishes a general “GCC Runtime Library Exception Rationale and FAQ”. (→ [6]) 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.’”

The question, whether also the libstdc++ itself may also be distributed under the terms of the runtime-exception is not clearly asked or answered. In the context of a question concerning the use of a completely proprietary compiler toolchain also this document suspends the copyleft effect, but mentions, that the library itself must be distributed by respecting the GPLv3. But note: this is an answer in the context of using a proprietary compiler toolchain and must not necessarily be transferred to the context of using the GCC compiler toolchain. Why? Because in case of the GCC compiler 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 on the other side the code using the library must nevertheless be published for fulfilling the condition, that the library must be replaceable by a better version.

So, now it is clear: YOCTO may integrate the libstdc++ into any image even if the GPLv3 is marked as INCOMPATIBLE_LICENSE. The strong copyleft effect of the GPLv3 is suspended by the Runtime Library Exception as well as the GPLv3 requirement to make the libstdc++ replaceable.

But that’s only valid for the libstdc++ and may not (automatically) be transferred 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.

Sources:

• [1] GPLv3 :- https://opensource.org/licenses/GPL-3.0
• [2] AGPLv3 :- https://opensource.org/licenses/AGPL-3.0
• [3] LGPLv3 :- https://opensource.org/licenses/LGPL-3.0
• [4] libstdc++ licensing document containg the libstdc++ GCC RUNTIME LIBRARY EXCEPTION :- https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html
• [5] libstdc++ FAQ :- https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.license.any_program
• [6] General GCC Runtime Library Exception Rationale and FAQ :- https://www.gnu.org/licenses/gcc-exception-3.1-faq.en.html
• [7] YOCTO project page :- https://www.yoctoproject.org/
• [8] YOCTO project development manual :- https://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html
• [9] 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

© Karsten Reincke: INSPECTION of 2019-06-30 about Compliance, FOSS, Open Source etc. with 1 comment. Published under the terms of the Creative Commons Share Alike license.
→ Commenting. | → Trackback-URI