Compliance

YOCTO, IoT, and the GPLv3

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

Yocto and GPLv3

IoT gad­gets often only offer inter­faces that do not allow inspect­ing or mod­i­fy­ing their soft­ware. YOCTO tries to build spe­cif­ic soft­ware for IOT gad­gets. And the GPLv3 requires that GPLv3-licensed soft­ware must be replace­able. Thus, YOCTO, IOT, and the GPLv3 are in a clinch, if YOCTO wants to be a dis­tri­b­u­tion for IOT devices that do not come with an update inter­face. And we might ask, how YOCTO deals with this con­tra­dic­tion?

[ en | de ]

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 the inte­gra­tion of 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, we can enforce to cre­ate 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 much 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 that 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 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 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 tech­niques to process a pro­gram and by which it talks to the ker­nel. They are nec­es­sary. Ulti­mate­ly, pro­gram­mers can­not pre­vent using 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 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 the use of the library in pro­pri­etary appli­ca­tions.” (→ [5] 2.2)

How does this work?

The copy­right own­ers of the lib­st­dc++ have expand­ed the mean­ing of the license by adding a clause: “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 we replace the weird terms by the mean­ing defined §0 of the lib­st­dc++ run­time excep­tion, we can eas­i­ly under­stand the sen­tence:

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 real­ly may 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 the 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 to dis­trib­ute lib­st­dc++ only in an envi­ron­ment, which allows a replace­ment.

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

This third doc­u­ment does not clear­ly address the top­ic of whether we may dis­trib­ute the lib­st­dc++ itself under the terms of the run­time-excep­tion. 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 it sus­pends the copy­left effect. And it states that we must dis­trib­ute the library itself 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. So, we may not auto­mat­i­cal­ly trans­fer it into the con­text of using the GCC com­pil­er tool­chain.

Why? Because in the case of the GCC com­pil­er-based 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 we — on the oth­er side — must nev­er­the­less pub­lish our code using the library 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 user has marked the GPLv3 as INCOMPATIBLE_LICENSE. The Run­time Library Excep­tion of the GPLv3 sus­pends the strong copy­left effect, 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++. You may not (auto­mat­i­cal­ly) trans­fer it 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.

And in what way is this …

… part of the over­ar­ch­ing top­ic FOSS Com­pli­ance? For ful­fill­ing the require­ments of FOSS licens­es, we have to con­sid­er spe­cif­ic indi­vid­ual cas­es as well as side effects — for soft­ware, pic­tures, or doc­u­ments. We should unhide trends and write guide­lines. Above all, how­ev­er, we must dri­ve for­ward the automa­tion of license ful­fill­ment, make our licens­ing knowl­edge freely avail­able, cast it into small­er tools, and bring it into larg­er sys­tems: Because FOSS thrives on free­dom through license ful­fill­ment, large and small. That’s what also this arti­cle is about.

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/
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    –

    Reply

Leave a Comment

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

To top