Compliance

YOCTO, IoT, and the GPLv3

/ by Karsten Reincke | 1 Comment on YOCTO, IoT, and the GPLv3

IoT gad­gets often only offer inter­faces which do not allow to inspect or to mod­i­fy their soft­ware. YOCTO tries to build spe­cif­ic soft­ware of IOT gad­gets. And the GPLv3 requires that GPLv3 licensed soft­ware must be replace­able. So, we might ask, how YOCTO deals with this con­tra­dic­tion?

The “open source col­lab­o­ra­tion project” YOCTO pro­motes itself with the slo­gan “it’s not an embed­ded Lin­ux dis­tri­b­u­tion, it cre­ates a cus­tom one for you” (→ [7]): You col­lect and com­pile exact­ly what soft­ware you need. And there­fore, you can also keep your IOT hard­ware sim­ple. That’s the YOC­TO-Idea. But some­times, the struc­ture of the hard­ware influ­ences the sat­is­fi­a­bil­i­ty of the license require­ments. And that could become thorny:

In gen­er­al, YOCTO knows the com­plex­i­ty of FOSS com­pli­ance and already sup­ports the prod­uct own­ers dur­ing the com­pi­la­tion process. For exam­ple, it lists all pack­ages and all the respec­tive licens­es (→ [8], 3.5). More­over, it allows inte­grat­ing the license texts into the image (→ [8], 5.20.2). And final­ly, it col­lects the cor­re­spond­ing code of the image for dis­trib­ut­ing it togeth­er with the prod­uct (→ [8], 5.20.1). These are impor­tant pre­vi­ous achieve­ments for gen­er­at­ing com­pli­ant images. [For being com­plete: these steps are nec­es­sary, but not suf­fi­cient. But that’s not our top­ic today.]

But the AGPLv3, the GPLv3, and the LGPLv3 require more. They pos­tu­late that the recip­i­ent of the soft­ware — the recip­i­ent of the IOT gad­get — must be able to replace the run­ning instance by an improved (or wors­ened) ver­sion, he him­self has com­piled (→ [1,2,3] §3): He must be able to install it on the hard­ware. If the IoT-gad­get gives him access to its filesys­tem by any inter­face, every­thing is fine: he can save his ver­sion on the gad­get, bend the cor­re­spond­ing link and restart the sys­tem. Bin­go. But what, if the IoT-gad­get does not offer such an inter­face? Or what, if the prod­uct own­er does not want to allow such a replace­ment for respect­ing legal secu­ri­ty rea­sons or for min­i­miz­ing his efforts to main­tain his cus­tomers?

Then — the answer is very clear — the prod­uct own­er must not dis­trib­ute any (A|L)GPLv3 licensed soft­ware as part of his prod­uct! Either one ful­fills the con­di­tions of the (A|L)GPLv3-licenses or one does not use soft­ware dis­trib­uted under the terms of these licens­es. There is no mid­dle course.!

Luck­i­ly, YOCTO sup­ports the devel­op­er on that score: It offers the oppor­tu­ni­ty to declare a vari­able INCOMPATIBLE_LICENSE as part of the recipe to cre­ate an image (→ [9] Chap­ter 10). If — lat­er on — the com­pi­la­tion process meets soft­ware licensed under licens­es exclud­ed by this method, then the process stops. Here­by, YOCTO can be enforced to cre­at­ed images with­out (A|L)GPLv3 licensed soft­ware. But then — as, the YOCTO hand­outs clear­ly state — YOCTO can cre­ate func­tion­al­ly restrict­ed images (→ [9] pars pro toto: Chap­ter 10) sim­ply due to the fact that many soft­ware is licensed under the GPLv3 so that it is exclud­ed by this tech­nique.

So far, so good. But there exists a core prob­lem which affects the devel­op­er more deeply:

Some stan­dard libraries — like for exam­ple the lib­st­dc++ — 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 men­tioned as an INCOMPATIBLE_LICENSE. Hence, one might now ask, whether YOCTO furtive­ly gen­er­ates non-com­pli­ant images? If one ana­lyzes the sit­u­a­tion more pre­cise­ly, one will see, that YOCTO is nev­er­the­less on the right way:

Stan­dard libraries offer the meth­ods by which a pro­gram is processed by the ker­nel and by which it talks to the ker­nel. They are nec­es­sary. Ulti­mate­ly, pro­gram­mers can­not pre­vent to use any stan­dard library. And if such a stan­dard library is licensed under a copy­left license, it direct­ly fol­lows from that, that all ‘high­er’ pro­grams or libraries using that stan­dard library have also to be licensed under the same copy­left license. The “GNU Stan­dard C++ Library v3” is such a stan­dard library. It describes itself as an “ongo­ing project to imple­ment the ISO 14882” (→ [5] 1.1) and as part of “GNU com­pil­er col­lec­tion” licensed under the GPLv3 (→ [5] 1.2) .

Nev­er­the­less, the lib­st­dc++ FAQ denies the ques­tion whether “[…] any pro­gram which uses lib­st­dc++ falls under the GPL” very clear­ly. It answers: “No. The spe­cial excep­tion per­mits use of the library in pro­pri­etary appli­ca­tions.” (→ [5] 2.2)

How does this work?

The mean­ing of the license is expand­ed by a method, the license itself offers. As it is said in the lib­st­dc++ license, “the source code is dis­trib­uted under the GNU Gen­er­al Pub­lic License ver­sion 3, with the addi­tion under sec­tion 7 of an excep­tion described in the “GCC Run­time Library Excep­tion, ver­sion 3.1” as fol­lows”. (→ [4])

And this addi­tion­al GCC Run­time Library Excep­tion states under §1:

You have per­mis­sion to prop­a­gate a work of Tar­get Code formed by com­bin­ing the Run­time Library with Inde­pen­dent Mod­ules, even if such prop­a­ga­tion would oth­er­wise vio­late the terms of GPLv3, pro­vid­ed that all Tar­get Code was gen­er­at­ed by Eli­gi­ble Com­pi­la­tion Process­es. You may then con­vey such a com­bi­na­tion under terms of your choice, con­sis­tent with the licens­ing of the Inde­pen­dent Mod­ules. (→ [4] §1)

On first glance, this is a hard-going sen­tence. But if one replaces the weird terms by the mean­ing defined §0 of the lib­st­dc++ run­time excep­tion, the sen­tence can eas­i­ly be under­stood:

The ‘Tar­get Code’ refers to any “[…] out­put from any com­pil­er for a real or vir­tu­al tar­get proces­sor archi­tec­ture, in exe­cutable form or suit­able for input to an assem­bler, loader, link­er and/or exe­cu­tion phase.” The Run­time Library is the lib­st­dc++ itself. And the ‘Inde­pen­dent Mod­ules are the com­piled ver­sions of those files which need the lib­st­dc++ for being exe­cut­ed. (→ [4])

Hence the first of the quot­ed sen­tences per­mits you to dis­trib­ute your com­piled pro­gram which needs the lib­st­dc++ for being exe­cut­ed even if you vio­lat­ed the GPLv3 by dis­trib­ut­ing it — pro­vid­ed that your com­piled pro­gram is gen­er­at­ed by an “Eli­gi­ble Com­pi­la­tion Process­es”.

A com­pi­la­tion process is defined as that process which “[…] trans­forms code entire­ly rep­re­sent­ed in non-inter­me­di­ate lan­guages designed for human-writ­ten code, and/or in Java Vir­tu­al Machine byte code, into Tar­get Code”. And such a com­pi­la­tion process “[…] is “ ‘Eli­gi­ble’ if it is done using GCC, alone or with oth­er GPL-com­pat­i­ble soft­ware, or if it is done with­out using any work based on GCC”. (→ [4])

So, the lit­er­al mean­ing of the first sen­tence of §1 of the lib­st­dc++ Run­time Excep­tion is, that you may propagate/distribute your com­piled C++ pro­grams requir­ing the lib­st­dc++ even if you vio­lat­ed the GPLv3 con­di­tions by that dis­tri­b­u­tion as long as you have com­piled all your c++ pro­grams and libraries by the GCC (or none of them). By this you cir­cum­vent the strong copy­left effect.

But in our case of IoT-gad­gets, that’s not all. The ques­tion is, whether we are also allowed to dis­trib­ute the lib­st­dc++ itself by vio­lat­ing the license. To answer that ques­tion, we need the sec­ond sen­tence of §1:

It says that we may con­vey = prop­a­gate = dis­trib­ute “[…] such a com­bi­na­tion under terms of your choice, con­sis­tent with the licens­ing of the Inde­pen­dent Mod­ules”. (→ [4] §1) And the com­bi­na­tion can noth­ing else than the com­bi­na­tion of our inde­pen­dent mod­ules, our pro­grams, AND the lib­st­dc++.

Bin­go! Real­ly? No!! In the case of copy­right ques­tions, it is, unfor­tu­nate­ly, not suf­fi­cient hav­ing under­stood the lit­er­al mean­ing of a license. One must also prove, that the copy­right own­ers use the same inter­pre­ta­tion. The intend­ed mean­ing is more impor­tant than the lit­er­al mean­ing of words. But in our case, it is not dif­fi­cult to do so:

The copy­right own­er of the GNU com­pil­er col­lec­tion is the FSF. And as the copy­right own­er, the FSF also offers a libstdc++-FAQ where it explains its own under­stand­ing of the GCC RUNTIME LIBRARY EXCEPTION in the con­text of the lib­st­dc++ (→ [5]) . And in this FAQ, you can find this:

On the one hand, the FSF asks whether “[…] any pro­gram which uses lib­st­dc++ falls under the GPL?”. And it answers, “No. The spe­cial excep­tion per­mits use of the library in pro­pri­etary appli­ca­tions.” (→ [5] 2.1) On the oth­er hand, the FSF clear­ly states in the FAQ, that the lib­st­dc++ can­not be replaced as sim­ple as oth­er libraries might be, because “much of the library con­sists of inline func­tions and tem­plates, which are expand­ed inside the code that uses the library” and replac­ing the library would also require to recom­pil­ing the using pro­gram. (→ [5] 2.3)

Hence, even from the lib­st­dc++ — FAQ, we can con­clude, that FSF sus­pends (a) the strong copy­left effect and (b) the require­ment, that the lib­st­dc++ must be dis­trib­uted in an envri­on­ment, which allows to replace it.

Unfor­tu­nate­ly, there is a third doc­u­ment, which seems to object to this under­stand­ing. The lib­st­dc++ is not the only library which is dis­trib­uted under the terms of the GCC run­time library excep­tion. There­fore, the FSF also pub­lish­es a gen­er­al “GCC Run­time Library Excep­tion Ratio­nale and FAQ”. (→ [6]) This doc­u­ment first­ly explains why they now intro­duce such a gen­er­al tech­nique of excep­tions. The sec­ond sec­tion explains how the excep­tion works which ends the mean­while known state­ment: “As long as you use an Eli­gi­ble Com­pi­la­tion Process, then you have per­mis­sion to take the Tar­get Code that GCC gen­er­ates and prop­a­gate it ‘under terms of your choice.’”

The ques­tion, whether also the lib­st­dc++ itself may also be dis­trib­uted under the terms of the run­time-excep­tion is not clear­ly asked or answered. In the con­text of a ques­tion con­cern­ing the use of a com­plete­ly pro­pri­etary com­pil­er tool­chain also this doc­u­ment sus­pends the copy­left effect, but men­tions, that the library itself must be dis­trib­uted by respect­ing the GPLv3. But note: this is an answer in the con­text of using a pro­pri­etary com­pil­er tool­chain and must not nec­es­sar­i­ly be trans­ferred to the con­text of using the GCC com­pil­er tool­chain. Why? Because in case of the GCC com­pil­er tool­chain and the nature of a c++ library, the FSF would cre­ate a self-con­tra­dic­to­ry require­ment: The sus­pen­sion of the strong copy­left on the one side would not hold, if on the oth­er side the code using the library must nev­er­the­less be pub­lished for ful­fill­ing the con­di­tion, that the library must be replaceable by a bet­ter ver­sion.

So, now it is clear: YOCTO may inte­grate the lib­st­dc++ into any image even if the GPLv3 is marked as INCOMPATIBLE_LICENSE. The strong copy­left effect of the GPLv3 is sus­pend­ed by the Run­time Library Excep­tion as well as the GPLv3 require­ment to make the lib­st­dc++ replace­able.

But that’s only valid for the lib­st­dc++ and may not (auto­mat­i­cal­ly) be trans­ferred to oth­er stan­dard libraries pub­lished under the GPLv3 with run­time excep­tion. It depends on the nature of a c++-library as well as of the text of the lib­st­dc++ run­time excep­tion.

Sources:

Tagged

One Comment “YOCTO, IoT, and the GPLv3”

  • Robert Berger

    says:

    Cool­er Artikel!

    Hier ein paar Kom­mentare

    1) “Nun fordert jede (A|L)GPLv” — da fehlt die 3. Bradley Kuhn sagt, dass dies auch fuer die v2 gilt[1], aber da wuer­den wohl viele andere wider­sprechen.

    2) “Dann – so die ein­fache Antwort – darf der Her­steller keine GPLv3, keine LGPLv3 und keine AGPLv3 lizen­zierte Soft­ware in seinem Soft­warestack ver­wen­den.” Die Antwort ist oft nicht ganz so ein­fach, denn wenn das Sys­tem etwas kom­plex­er wird, dann ist es schw­er keine xGPLv2 Soft­ware zu ver­wen­den. Ein “Workaround” waere, wenn man in das Man­u­al rein­schreibt, dass man ein “spezielles” Image auf Anfrage anbi­eten kann, welch­es es dann erlaubt die xGPLv3 Kom­po­nen­ten durch andere Ver­sio­nen zu erset­zen — allerd­ings fehlt in diesem Image dann Einiges an pro­pri­etaerem Code.

    3) “Der Kom­pi­la­tionsvor­gang bricht dann ab, wenn Entwick­ler trotz­dem so lizen­sierte Soft­ware ein­bauen.” — Mit viel Glueck sucht das Buildsys­tem auch noch nach Alter­na­tiv­en, die ver­suchen die
    xGPLv3 Kom­po­nente dur eine Kom­po­nente mit ander­er Lizenz zu erset­zen.

    4) “in sein Image, auch wenn die Bele­gung der Vari­able INCOMPATIBLE_LICENSE dies eigentlich ver­hin­dern müsste.” — wie diese Lib, wie auch viele andere under xGPLx lizen­sierte Libs spezielle Lizenz “Excep­tions” bein­hal­tet, die z.B. “derivate Work” und andere Dinge wieder aus der Lizenz raus­nehmen.

    5) “lib­st­dc++” Man schafft es uebri­gens nicht mit dem Yoc­to Project nur die lib­st­dc++ in das rootfs aufzunehmen ohne z.B. min­destens ein hello-world.cpp zu haben, dass gegen die lib linkt, d
    enn nur die lib­st­dc++ waere nicht erlaubt.

    6) Was die std C lib aufruft (sys­tem calls) ist auch span­nend, denn dazu braucht man spezielle Ker­nel head­ers, die mit GPLv2 plus excep­tion lizen­siert sind.

    7) In ein­er aktuellen Yoc­to Ver­sion (mom­e­natn in mas­ter) ab Honister/3.4 offiziell kann man ein SBOM (Soft­ware Bill of Mate­r­i­al) gener­ieren, welch­es mit dem entsprechen­den Tool­ing Open Source Soft­ware Com­pli­ance hof­fentlich nich bess­er machen wird (bis jet­zt wer­den nur einzelne recipes und kein “com­bined work” betra­chtet).

    8) Manche Fir­men machen open source meta lay­ers und damit kann man ein Image bauen und auf das Ger­aet laden, was auch inter­es­sant ist.

    [1] https://sfconservancy.org/blog/2021/jul/23/tivoization-and-the-gpl-right-to-install/

    –
    Robert Berg­er
    Embed­ded Soft­ware Evan­ge­list

    Reli­able Embed­ded Sys­tems
    Con­sult­ing Train­ing Engi­neer­ing
    URL: https://www.reliableembeddedsystems.com

    Sched­ule a web meet­ing:
    https://calendly.com/reliableembeddedsystems/
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    –

Leave a Comment

Your email address will not be published. Required fields are marked *

To top