Qt-licenties voor embedded devices

Een commercieel product met Qt betekent niet automatisch dat je een commerciële Qt-licentie nodig hebt. Je kunt Qt onder de LGPLv3 meeleveren en je eigen applicatie gesloten houden. Of dat voor jouw toestel werkt, hangt af van de modules die je gebruikt, van het soort toestel en van de vraag wie Qt de komende jaren bijwerkt.

We schrijven dit als engineers die HMI’s bouwen. Het is dus geen juridisch advies: controleer altijd de voorwaarden van de Qt-versie die effectief op je image staat.

Commercieel of LGPLv3

The Qt Company biedt Qt aan onder een commerciële licentie en onder open-source licenties. Voor de meeste libraries is die open-source licentie de LGPLv3. Je applicatie mag dan gesloten blijven, op voorwaarde dat je de verplichtingen rond de Qt-libraries zelf nakomt.

In oudere blogposts lees je nog vaak over de LGPLv2.1. Die versie had geen regels over toestellen die op slot zitten. Sinds Qt 5.7 wordt Qt niet meer onder de LGPLv2.1 uitgebracht. Het klassieke advies “link dynamisch en je mag het toestel gewoon dichtzetten” klopt voor recente versies dus niet meer.

Begin bij de modules die je gebruikt

Niet elk Qt-onderdeel valt onder de LGPL. In Qt 6.11 zijn onder andere Qt Virtual Keyboard, Qt Wayland Compositor, de Qt Qml Compiler, Qt Quick 3D, Qt Graphs en Qt MQTT in de open-source versie enkel onder GPLv3 beschikbaar. Die lijst verandert van release tot release. Kijk dus op de licentiepagina van de versie die je effectief meelevert, want een oude FAQ kan achterlopen.

Link je zo’n module in hetzelfde proces als je HMI, dan valt je volledige applicatie onder de GPL. En het zijn net onderdelen als het schermtoetsenbord, een eigen compositor, de QML-compiler of een MQTT-client die in een project snel even worden toegevoegd.

Wayland op je Yocto-image is een apart geval. Draait er Weston, Cage of de compositor van je boardleverancier, en is jullie Qt-applicatie gewoon een venster daarin, dan gebruik je de Wayland-clientplugin. Die valt onder de LGPL. Je hoeft Wayland daarvoor zelfs niet te vermelden in de CMake-bestanden van je applicatie: Qt laadt de plugin automatisch zodra WAYLAND_DISPLAY gezet is.

Het GPL-onderdeel, Qt Wayland Compositor, komt pas in beeld als jullie programma zelf de display server is. Dat herken je in de build aan Qt6::WaylandCompositor, of in QML aan een import van QtWayland.Compositor. Staat dat er niet in, dan maakt Wayland op het image je applicatie niet GPL.

Let ook op licenties die via een LGPL-module mee binnenkomen. Qt WebEngine is gebaseerd op Chromium, en Qt Multimedia geeft je geen patentlicentie voor H.264 of H.265. Voeg daarom de attribution-bestanden van je Qt-versie toe aan elke release, samen met de LGPL-tekst.

Twee verschillende plichten

De LGPL is goed bruikbaar in commerciële producten: een gesloten HMI die dynamisch tegen Qt linkt, mag je gewoon verkopen. Waar het in de praktijk vaak misloopt, is dat twee verschillende plichten door elkaar worden gehaald.

Qt als .so meeleveren moet altijd. Dat je klant die .so op het toestel kan vervangen, is alleen verplicht bij een User Product.

De eerste plicht komt uit LGPLv3 sectie 4(d). Je applicatie linkt dynamisch tegen Qt, zodat ze ook met een andere, interface-compatibele versie van die library kan draaien. Daarnaast lever je de licentietekst mee, bewaar je de broncode van Qt zoals die op het image staat (met jullie eigen patches erbij) en verbied je in de EULA niet dat iemand die library aanpast. Patches op Qt zelf vallen onder de LGPL. De code van je HMI blijft van jou.

Die eerste plicht gaat dus over je build. Een read-only rootfs met secure boot kan de .so gerust vastzetten, zolang het een gedeelde library blijft en niet in je applicatie is ingebakken. Statisch linken kan ook, maar dan moet je de objectbestanden meeleveren zodat iemand opnieuw kan linken, en dat wil je bij een gesloten HMI meestal niet. Op een microcontroller zonder dynamische linker kom je uit bij Qt for MCUs, en dat is een commerciële licentie.

De tweede plicht staat in sectie 4(e), die verwijst naar sectie 6 van de GPLv3. Het gaat om de zogenaamde Installation Information: de signing keys, de procedure of een andere manier waarmee de ontvanger een aangepaste Qt op dat specifieke toestel kan installeren en opstarten. Die plicht geldt alleen voor een User Product. Voor een display op een productiemachine, die normaal enkel industrieel gebruikt wordt, geldt ze niet. Je klant hoeft libQt6Core.so dan niet in het veld te kunnen vervangen, en je hoeft de keys van je secure boot niet te delen.

De broncode moet je wel altijd bewaren, ook voor die machine. Een schriftelijk aanbod onder GPLv3 sectie 6 blijft minstens drie jaar geldig, en daarna zolang je voor dat model onderdelen of support levert. Ondersteun je een machine tien jaar, dan bewaar je het archief van die Qt-build ook tien jaar: de layers, revisies en patches. Leg het vast bij de release, zodat het niet afhangt van de laptop van wie het image ooit gebouwd heeft.

Wanneer is een toestel een User Product?

Een User Product is een consumentenproduct: iets dat normaal gebruikt wordt voor persoonlijke, gezins- of huishoudelijke doeleinden. Ook producten die ontworpen of verkocht worden om in een woning te worden ingebouwd, vallen eronder. In twijfelgevallen kiest de licentie voor de bescherming van de gebruiker. Doorslaggevend is hoe dat soort product normaal gebruikt wordt. Of deze ene koper toevallig een bedrijf is, speelt geen rol.

Een product dat ook industrieel gebruikt wordt, blijft een consumentenproduct, tenzij industrieel gebruik de enige gangbare toepassing is. Dat je aan een machinebouwer factureert, volstaat op zich dus niet.

Wat je bouwt	Hoe we het bekijken
Smart-home of een ander consumententoestel	Huishoudelijk gebruik, dus reken op een User Product en op de tweede plicht.
Wandpaneel voor een woning, verkocht aan installateurs	Het is gemaakt om in een woning te worden ingebouwd. Dat je aan installateurs verkoopt, verandert daar niets aan.
Display dat alleen op een productiemachine zit	Als dit soort toestel nergens anders voor dient, valt het buiten de definitie. De eerste plicht blijft wel gelden.
Medisch toestel voor thuis	Thuisgebruik telt als huishoudelijk gebruik, ook bij een medisch toestel.
Scherm in een voertuig of op een trekker	Infotainment voor de bestuurder is iets anders dan een ECU die alleen in de machine zit. Bekijk ze apart.
Twijfel	Volgens de licentie behandel je het dan als User Product, of neem je een commerciële licentie. Uitgaan van “waarschijnlijk industrieel” is een risico dat je beter niet neemt.

Secure boot

Secure boot is een beveiligingsmaatregel en heeft op zich niets met de licentie te maken. Op een User Product mag je de Qt-library wel niet afschermen met keys die alleen jij hebt: de eigenaar moet een aangepaste versie kunnen installeren en starten. Je hoeft die aangepaste versie daarna niet te ondersteunen, en je mag de toegang tot je netwerk weigeren als de wijziging dat netwerk schade toebrengt.

Er bestaat een uitzondering voor software die niemand meer kan vervangen, ook de fabrikant zelf niet, zoals code in ROM. Een bootloader waarmee je zelf nog updates ondertekent, valt daar niet onder. Zolang jij nog nieuwe software kunt installeren, moet de eigenaar van een User Product dat ook kunnen.

Op een display van een productiemachine geldt die installatieplicht niet, en kan secure boot met je eigen keys gewoon onder de LGPL. Je moet dan nog wel de eerste plicht nakomen: dynamisch linken, de broncode van Qt bewaren en de licentietekst tonen. Op een consumententoestel kan datzelfde slot alleen als de eigenaar alsnog een aangepaste Qt kan draaien.

Waarom een commerciële licentie toch de moeite kan zijn

Voor veel machine-displays is de LGPL juridisch geen probleem. Op lange termijn kan het toch de duurdere keuze blijken, en dat heeft vooral met patches te maken.

Een gewone Qt-release krijgt ongeveer een jaar ondersteuning, een LTS-release langer. Vanaf Qt 6.8 is dat vijf jaar voor commerciële klanten; Qt 6.8 LTS loopt tot oktober 2029. Met een commerciële licentie krijg je die patches meteen, de open-source versie krijgt ze later. Door de afspraak met de KDE Free Qt Foundation mogen die wijzigingen hooguit ongeveer een jaar uit de vrije editie worden gehouden.

Gaat je toestel tien of vijftien jaar mee en moet je al die tijd beveiligingsupdates kunnen leveren, dan moet je dat verschil op een of andere manier opvangen. Je kunt de open-source tak blijven volgen en de API-wijzigingen telkens meenemen. Je kunt een versie bevriezen en zelf patchen, ook Qt WebEngine als die op je image staat. Of je kiest voor Device Creation en laat The Qt Company die tak onderhouden.

Met de LGPL bespaar je dus op licentiekosten, maar het opvolgen van kwetsbaarheden in Qt blijft bij jullie team liggen.

Welke route kies je?

Met Qt for Device Creation vallen de LGPL-plichten voor het framework weg, en mag het toestel onder die voorwaarden ook op slot. Die keuze ligt voor de hand als een van deze situaties op jou van toepassing is:

• Je HMI heeft een module nodig die in de open-source versie alleen onder de GPL valt, en die draait in hetzelfde proces.
• Je bouwt een User Product, of je twijfelt, en het toestel moet op slot met keys die de eigenaar niet krijgt.
• Je wilt jarenlang patches rechtstreeks van Qt, zonder dat werk zelf in het team te moeten dragen.
• Er is geen dynamische linker. Dan kom je uit bij Qt for MCUs, en niet bij de LGPL op Linux.

Voor een display op een industriële machine blijft de LGPLv3 een goede optie, zolang aan een paar voorwaarden voldaan is. De modules die je linkt vallen onder de LGPL, Qt staat als .so op het image en je bewaart de broncode zolang je de machine ondersteunt. En iemand in het team volgt de Qt-patches op die niet meteen in de open-source versie terechtkomen. De klant hoeft die .so dan niet zelf op de machine te kunnen vervangen.

Neem de beslissing vroeg

Het loont om dit uit te zoeken terwijl je image nog volop in ontwikkeling is. Begin bij de modules die de HMI echt gebruikt en controleer of je dynamisch linkt, wat voor een Linux-HMI de gebruikelijke aanpak is. Zorg dat het archief van de build in orde is. Ga daarna na of je toestel een User Product is, want alleen dan bepaalt je secure-boot-opzet of de .so vervangbaar moet blijven. De licentietekst in het About-scherm volgt daar dan logisch uit.

Een prototype kan gerust met de open-source pakketten starten. Overschakelen wordt pas duur als het schermtoetsenbord al in het proces zit, de keys al in het toestel gefused zijn en er beloofd is dat die combinatie tien jaar lang patches krijgt.

Bij Invisto bekijken we dit als één geheel: de BSP, het image, de update-aanpak en de HMI. Zo hoort de licentiekeuze bij dezelfde release als de keys en de modules.