Skip to content

Using Qt 5.15 and Qt 6 under LGPLv3

Nearly exactly 5 years ago, I wrote my first article about Using Qt 5.6 and Later under LGPL. The trigger then was the switch from LGPLv2.1 to LGPLv3 with Qt 5.6. The trigger now is the switch from Qt 5 to Qt 6. All the Qt modules under LGPLv3 5 years ago are still available under LGPLv3 – unless they have been retired. Some new modules like Charts, CoAP and MQTT were only available under Qt Commercial until Qt 5.15, but are now available under the new Marketplace license for 50-300 USD per year (no royalties). Some new modules like Quick 3D and WebAssembly are only commercially available. All in all not much changed: You can still build fantastic HMIs with Qt LGPLv3.

Qt Modules under LGPLv3

All essential Qt modules are available under LGPLv3 from Qt 5.15 to Qt 6.2. The two Multimedia modules will be included from Qt 6.2. They didn’t make it into Qt 6.0 and Qt 6.1.

All essential Qt modules are available under LGPLv3
Essential Qt modules: all under LGPLv3

The next two tables show the Qt add-on modules that are available under LGPLv3. The modules OpenGL, Quick Controls 1, Script and Xml Patterns are obsolete in Qt 6 (marked “XXX”). It could be that the Android, Mac, X11 and Windows Extras modules are obsolete in Qt 6. I have seen contradicting messages.

The SerialBus, SerialPort and RemoteObjects modules, all Web modules and some other modules won’t be available before Qt 6.2. Then, they will be available under LGPLv3.

Qt add-on modules available under LGPLv3
Qt add-on modules under LGPLv3 (Part 1)
Qt add-on modules available under LGPLv3
Qt add-on modules under LGPLv3 (Part 2)

Commercial Qt Modules

The next two tables show the Qt add-on modules, which come under different commercial licenses. I haven’t found any official statements about the migration plans for the modules Application Manager, Qt for WebAssembly, Quick WebGL and Wayland compositor. Hence, I marked them with “???”. I’d assume that they will be continued in Qt 6 under the same commercial license as in Qt 5.15.

Qt add-on modules available under commercial or marketplace license
Qt modules under commercial licenses (Part 1)

Qt 5.15 has seen the introduction of the marketplace license. This license allows you to combine commercial Qt modules like Charts, MQTT and CoAP with an application using Qt under LGPLv3. The license comes as a yearly subscription ranging from 50 to 300 USD. You can use the modules on as many devices as you want as long as you pay for the subscription.

MQTT, CoAP and OPC UA cost 129 USD each. KNX and PDF go for 49 USD each. Charts is priced at 199 USD and the bundle of the Design Studio Bridges for Photoshop, Figma and Sketch at 300 USD. Given these very fair prices, it’s not even worth discussing whether to develop some of their functionality on your own. Just buy the module, if it fits your requirements.

The Qt OPC UA is once implemented with the stack Open62541 v1.0 under MPLv2 (Mozilla Public License) and once with the commercial stack UACpp from Unified Automation. The Qt module provides a common API for both stacks, which is also licensed under LGPLv3. As the MPLv2 is compatible with the LGPLv3, the Qt OPC UA module is also available under LGPLv3 – for the Open62541 stack.

Qt add-on modules available under commercial or marketplace license
Qt modules under commercial licenses (Part 2)

Qt for Device Creation is the standard commercial offering for embedded systems. You must pay both a per-developer and a per-device fee (royalties). You pay 4000-5000 USD per year per developer. You get some good discounts on the number of developers and on the number of years.

At a volume of 200 devices, the per-device fees are in the range from 10 USD to 15 USD. At 100 devices, the fees are 40-50 USD. You can get discounts, if you buy deployment licenses for the next 3, 5 or even 10 years, that is, if you buy higher volumes.

Qt for Device Creation provides pre-built Boot2Qt images for many widely used SoCs, computer-on-modules and SBC made by NXP, Nvidia, Intel, Texas Instruments, Raspberry Pi Foundation, ST, Toradex, Boundary Devices, Kontron and many others. The pre-built images save you the time to build the images yourself. As you customise the Linux images to your needs, you will inevitably end up changing Yocto recipes and building the images yourself.

The pre-built Boot2Qt images mainly save you the compute time for building the Linux images with Yocto. The BSPs of most board and SBC makers contain all the Qt modules, some Qt example applications (auto-starting at boot time) and the Wayland Weston window manager. The BSP and SDK builds run smoothly most of the time – especially when you follow descriptions like Building a Linux Image with Yocto (and Docker) and Building a Qt SDK with Yocto.

The installation of a commercial Boot2Qt image sets up QtCreator for cross-compilation, for deploying your Qt application to the device, for running it on the device and for remote debugging. So, you can immediately start developing your Qt application for controlling and supervising your machines – without doing all the setup tasks yourself. This QtCreator setup is a real time-saver. I have described how to do this setup for an embedded Linux system using Qt LGPLv3 in a recent post.

It’s fair to say that Qt for Device Creation speeds up the time until you can start developing your Qt application. You are up and running within an hour. As a maker of embedded devices, building a Linux system with Yocto and setting up your development environment isn’t your main goal any way. So, any time you save on non-essential tasks is welcome.

Qt for Device Creation includes all the Qt modules marked “Comm” with red background like Virtual Keyboards, Application Manager, Wayland Compositor and Quick 3D. All the “Comm” modules are also available under GPLv3.

The Qt Company removed LGPLv3 licensing from the Application Manager and the Wayland Compositor in Qt 5.14 (see this post on the Qt blog). This is not a big deal. You could develop your own application and window manager based on Qt 5.13. Or, you can use and extend Weston, the default Wayland compositor, which is under the MIT Expat license. The BSPs of all the computer-on-module and SBC makers such as Toradex, Boundary Devices, Kontron, Variscite and Seco build Weston by default.

A window and application manager enables you to use different GUI framework for different applications and to use different licenses for different applications. When you compose the applications into one window, they look like a single application. Users cannot tell the difference. Here are two examples:

  • You could use any third-party 3D framework to display video for interactive surgery and pack it into an application of its own. Two GUI frameworks in one application are typically an integration nightmare.
  • You could put Qt Virtual Keyboard together with a communication API into an application of its own and release the whole application under GPLv3. As the keyboard hardly ever provides a competitive advantage, open-sourcing the applications code shouldn’t be a problem (see Episode 30 of the FOSS North podcast for more details).

You get all the modules under commercial (“Comm”) and marketplace (“market”) license with the Qt for Small Business offering. The license, which was introduced in spring 2020, doesn’t include any deployment licenses. You qualify for the Qt for Small Business license, if your revenue as a company or individual is under 250,000 USD per year. You pay 500 USD per year for the license.

Qt for MCU is the offering for running Qt on microcontrollers (MCUs). It provides the code to bring-up Qt on bare-metal systems or on RTOSs. It also provides the Ultralite version of Qt Quick. The firmware with Qt can fit into 6MB of RAM and flash. The license costs are in the upper 5-digit USD range per project. Although Qt for MCU is a technical masterpiece, I’m a bit skeptical about its business success.

  • MCUs powerful enough to run Qt GUIs smoothly are more expensive than, say, an i.MX6ULL with a Cortex-A7 application processor and Linux. It’s a lot easier to find developers for an embedded Linux system running on a microprocessor than for a bare-metal or RTOS system running on a microcontroller.
  • As soon as the firmware of a microcontroller controls a machine, the control code is most likely safety-critical. Then, it’s advisable to separate the safety-critical code from the non-safety-critical code, that is, the GUI code. The separation reduces the certification efforts significantly. You get this separation naturally when you use hybrid SoCs like the NXP Vybrid, i.MX7 or i.MX8. The GUI runs on the microprocessor and the control code on the microcontroller.

Qt Safe Renderer allows you to show some indicators (icons or text) inside an otherwise unsafe GUI application. Even if the GUI application crashes, the indicators are guaranteed to be shown on the screen. Buttons are currently not supported. This guarantee is possible, because the safe renderer is certified to SIL 3 and ASIL D for road vehicles, SIL 4 for railway vehicles and “fit-for-use” in medical devices. This makes a price in the upper 5-digit USD range seem like a bargain.

I am not sure whether Qt for Automation is still sold as an independent offering, as its main parts like CoAP, MQTT, KNX and OPC UA are all available under the marketplace license. Qt for Automation provides pre-built Boot2Qt images for the most common SoCs. The images contain the Qt modules relevant in the automation domain.

Qt Automotive Suite contains a reference implementation for an in-vehicle infotainment system, the GUI components, the middleware and some tooling to generate the UI from the designs and run the UI design directly on the target device. The license costs are in the 6-digit USD range per project.

Qt Tools

Almost all design and development tools for Qt are available under GPLv3. This means that you can use the output of all the tools to develop and deploy your applications under any of the three Qt licenses. Trusted tools like Qt Creator, qmake, moc, rcc. Qt Assistant, Qt Linguist and Qt Installer fall into this category.

UX designers use Qt Design Studio to create 2D and 3D QML designs. When designs from Photoshop, Figma or Sketch are imported, Qt Design Studio generates QML code. Designers can adapt the GUIs graphically and run the GUIs on the target device. All the 2D features come under GPLv3. Even if the 3D features of Qt Design Studio come under GPLv3 (I don’t know), you must not use the generated QML 3D code in a Qt application using Qt LGPLv3. The Qt Quick 3D module is only available under Qt GPLv3 or Qt Commercial.

Qt Quick Compiler became available under GPLv3 in Qt 5.12. It converts QML code into C++ code, which is compiled along the other Qt/C++ code into machine code. This makes animations smoother and the application startup faster (see my post 30% Faster Startup Thanks to QtQuick Compiler) – just by switching on a configuration option in your make file.

QmlLive – also under GPLv3 – seems to be a useful tool. I have seen some demos, but I haven’t used it yet. QmlLive reloads the QML scene whenever a QML file changes. It shortens “the classic edit-save-run-exit cycle”.

The Big Question: To Use Qt LGPLv3 or Qt Commercial

When customers ask me, whether they shall use Qt LGPLv3 or Qt Commercial, I show them the following cost comparison.

Total cost for embedded Linux system with Qt LGPLv3 vs. Qt Commercial
Total cost for embedded Linux system with Qt LGPLv3 vs. Qt Commercial

A typical Qt embedded Linux system built with Yocto is made up of 500 packages. For every package, you must ensure that you comply with its license. The 500 packages easily come with 100 different FOSS licenses (e.g., MIT, BSD-2, BSD-3, LGPLv2.1, LGPLv3, GPLv2, GPLv3, MPLv2, EPL, Apache) and some commercial licenses from the SoC vendors. In my talk Using Qt under LGPLv3, I explain how to satisfy the obligations of LGPLv3 and how to check the license compliance for an embedded Linux system.

I have done such license compliance checks for half a dozen customers. The costs in the left table are derived from my experience. A company will pay roughly 40,000 USD over 5 years for license compliance.

These costs will also arise, if the company buys a Qt for Device Creation license (Qt Commercial). In addition to these costs (given above the sum), the company must pay the per-developer and per-device fees for Qt Commercial. For 3 developers and 1000 units, you look at an annual cost of roughly 21,000 USD. The total cost for the embedded Linux system with Qt Commercial is 142,000 USD.

Please note that the cost for embedded Linux systems with Qt Commercial depends on the number of developers and devices. The cost for systems with Qt LGPLv3 stays the same, no matter how many developers work on the project and no matter how many devices you produce. Also note that the prices are estimates based on what I hear from well-informed resources. Of course, you should ask the Qt sales people for the exact prices and use them in the above calculation.

The initial question “Shall I use Qt LGPLv3 or Qt Commercial?” boils down to “How can I save development efforts worth 100,000 USD?” or “How can I earn 100,000 USD by launching my product earlier?”

I’d make you look at the red “Comm” modules in the tables above and make you figure out how much time a workaround without Qt Commercial takes. For example, you could put Qt Virtual Keyboard into an application of its own and use Weston as a window manager (as described above). Alternatively, you could implement an on-screen keyboard yourself, use it in your main Qt application and don’t use Weston. You’d come up with effort estimates for both solutions. You would do that for all red “Comm” modules and come up with a time and cost estimate.

You should also look at the features that Qt for Device Creation offers. If you choose a hardware platform supported by Boot2Qt, you can save quite a bit of time – especially if you have never built a Linux system with Yocto. You can start from a working Linux image, which you can customise step by step according to your needs. Qt Creator is set up for building, deploying, running and debugging for the target device right out of the box. Static linking saves you considerable time in getting to system startup times of less than 3 seconds.

You add the cost estimates for all these activities to the roughly 40,000 USD in the left table. This gives you the total cost for developing your embedded Linux system with Qt LGPLv3. You compare the final sums of the left and right table and have a fairly objective answer whether to use Qt LGPLv3 or Qt Commercial. And – you take the decision!

Need Help with License Compliance?

Here is a link to my free resources about Qt licensing. It is a list of posts I have written and of talks I have given over the years.

I also offer license compliance checks for complete embedded Linux systems as a productised service for a fixed price. The service is divided into three options, where each option includes the previous option.

  • Option 1: I guide you to the decision whether to use Qt LGPLv3 or Qt Commercial in your project.
  • Option 2: I check that all the packages in your embedded Linux system comply with their licenses.
  • Option 3: I teach you how to do the compliance check yourself in the future.

If you are interested in a license compliance check for your Qt embedded Linux system, then hit the button below and send me an email with brief information about your project. I’ll respond with an invitation for a video conference.


On 2021-04-22: In the original version of the post, I used 5700 EUR as the per-developer fee in the cost comparison between Qt LGPLv3 and Qt Commercial. The price should be in USD. It also disregards the considerable discount when you sign up for 3-5 years. So, the per-developer fee should be between 4000-4500 USD. The critical question then becomes “How can Qt Commercial save or make you an extra 100,000 USD?” – instead of 140,000 USD.