Skip to content

Using Qt 5.6 and Later under LGPL

Up to Qt 5.3, things were pretty simple. Most modules were under LGPLv2.1 with the exception of some commercial modules. Starting with Qt 5.4, new Qt modules were published under LGPLv3 and old modules additionally under LGPLv3. With Qt 5.6, we now have quite a patchwork of modules under different licenses. Qt 5.7 will drop LGPLv2.1 completely. Some companies stay on Qt 5.3, because they are afraid of LGPLv3. Let me bring some clarity into this patchwork and explain how you can still use Qt under LGPL and sleep well.

Using Qt under GPL or commercial license

Let me start with the easy cases. If you use Qt under commercial license, nothing has changed for you. You can simply use Qt as before. Of course, you must pay for one license per developer. And, if you deploy your Qt application on an embedded device, you must pay royalties. Once you have paid, you have the all-around carefree package.

From Qt 5.7, the Qt source code of the commercial license will be (almost) identical to the Qt source code under GPL. This is at least the stated goal of The Qt Company. Even modules like the virtual keyboard, the software renderer for QML without OpenGL and the unit-test integration into QtCreator will become available under GPL.

There is one notable exception in Qt 5.7, which will not be available under GPL. The QtQuick or QML compiler will only be available under commercial license. The plan for Qt 5.8 is to merge the QML compiler into the Qt Declarative module and then make the QML compiler available under GPLv2, LPGLv3 and commercial license.

The GPL world will be as nice and carefree as the commercial world from Qt 5.8. Of course, you must be willing to open-source your software. This is certainly a good option for universities and open-sources projects, but not for companies.

If neither GPL nor commercial license is for you, there is a third option with the LGPL. And that’s where things are most confusing.

Using most of Qt with LGPLv2.1 up to v5.6

The following diagram shows the Qt licensing landscape for Qt 5.6.

qt-licenses-up-to-5.6

All the modules available under LGPLv2.1 – with the exception of the WebEngine module – are also available under LGPLv3. WebEngine depends on third-party code from Chromium and hence cannot be bumped up to LGPLv3. The “dual” licensing with LGPLv2.1 and LGPLv3 was introduced in Qt 5.4. New modules introduced with Qt 5.4 or later are published under LGPLv3 only. This is why modules like 3D, QuickDialogs and QuickControls are under LGPLv3.

The above diagram can also be used for versions before Qt 5.6 if you keep the following in mind. If a Qt module exists in an earlier version, it is available under the same license as shown in the diagram. From Qt 5.3 back to 5.0, you wouldn’t find any modules under LGPLv3 (no green modules).

The box labelled “Other Tools” in the above diagram stands for tools like QtCreator, qmake, moc, rcc, lupdate, lrelease and linguist. They are all available under GPL. This isn’t a problem for use in a commercial setting, because these are standalone tools running in their own process and definitely not linked into your application. The code produced by tools like qmake, moc and rcc is not under GPL but can be used freely in closed-source software. This is similar to the code produced by the GPLed gcc and g++ compilers.

The black modules like the QML compiler, virtual keyboard and the 2D software renderer for QML are only available under the commercial Qt license. The Qt Company does this to motivate you to buy Qt licenses. Well, somehow they have to pay for the development of a fantastic product!

If you have no problem with LGPLv3, you can use all the modules of Qt 5.6 except for the commercial ones (the black ones). I know, however, that there are quite a few companies out there for whom LGPLv3 is a no-go. Some companies even stick with Qt 5.3, which is the last version without any LGPLv3 modules. I think this is slightly paranoid.

These companies could simply restrict themselves to using the blue modules under LGPLv2.1. If they keep their fingers off the few green modules under LGPLv3, they can happily use Qt under LGPLv2.1. And – they can do so for another three years, because Qt 5.6 comes with long-term support (LTS).

The Qt Company made Qt 5.6 an LTS version to give companies enough time to get their heads around LGPLv3 and to move from LGPLv2.1 to LGPLv3. Long-term support means that Qt 5.6 will receive bug fixes, security patches and the occasional new feature during these three years. If you want any support for Qt 5.6 beyond 2019, you have to pay for it or do it yourself.

Using most of Qt with LGPLv3 from Qt 5.7

The following diagram shows the Qt licensing landscape for Qt 5.7 and future versions.

qt-licenses-from-5.7

The big difference to the first diagram is that all the blue modules (LGPLv2.1) have turned into green modules (LGPLv3) – except for the WebEngine module, which will stay under LGPLv2.1. In other words: Qt will drop LGPLv2.1 completely from Qt 5.7.

The commercial modules from Qt 5.6 will still be available under commercial license from Qt 5.7 but will also become available under GPL – with the exception of the QML compiler. This means that you still cannot use these modules in closed-source software. It would taint your software with the GPL.

The QML compiler will stay under commercial license for Qt 5.7. However, it will be integrated into the QtDeclarative module for Qt 5.8 and will be available under LGPLv3, GPLv2 and commercial license from Qt 5.8 onwards. Tuukka Turunen describes the features of the QML compiler in his post Qt Roadmap for 2016 perfectly:

The new Qt Quick Compiler will be built into Qt Declarative providing two modes. In the Runtime mode it provides a storage (cache) of just in time compiled code on disk making second runs faster. In the Build time mode it works similar to the currently available Qt Quick Compiler, i.e. compiling QML to C++ during the application build time. Therefore, it makes also the first run faster and secures the source code better against reverse engineering.

The best thing is that the QML compiler will be available under LGPLv3! This is a pretty good deal!

How to Comply with LGPLv3

When you use Qt under LGPLv3, you have three main obligations.

  • Your application should link the Qt libraries as shared libraries.
  • You must make the Qt sources – including your modifications to the Qt sources – publicly available. For example, you can make available the Qt sources on your website or on GitHub for download. You can keep the source code of your application closed.
  • You must enable users to build the Qt sources for the target device (e.g., an infotainment system in a car or a washing machine), deploy the Qt libraries on the target device and run the original application using the modified Qt libaries on the target device.

The first two obligations are the same as for LGPLv2.1. They are well-known and well-understood. The third obligation is the so-called “anti-tivoisation clause“, which is Section “4. Combined Works” of LGPLv3 . It actually forbids to fully lock down a device using software under LGPLv3. A full lock-down was possible with LGPLv2.1 and was widely used.

The third obligation is the one that causes companies the most headaches. Let me explain in detail what this obligation means for embedded devices.

You must provide a cross-compiling toolchain together with the necessary libraries, headers, files and tools such that users can build the modified Qt version for the target device. A pretty simple way to satisfy this obligation would be to install the toolchain in a virtual machine and make this virtual machine available to the users.

Don’t worry. You do not have to ensure that your application links against any modified Qt version. LGPLv3 requires the modifications of the Qt libraries to be interface-compatible. Users are required to ensure that their modified Qt libraries still link against the original application. It is the users’ duty – not yours – to fix linking problems.

Furthermore, you must provide a way to deploy the application (typically, the binary file) and the new Qt version on the target device. This could be as simple as transferring the application and the Qt libraries to the target device by a USB drive – with a little twist. When the user has plugged a USB drive into the embedded device and power-cycles the device, the device starts an updater instead of the actual application. The updater asks for a password, which is specific to the device, explains the dire consequences of installing a modified Qt version like losing your warranty, and installs the application binary and the Qt libraries.

The described update mechanism is pretty common for agricultural machines to update the software on the machines and can be used for complying with LGPLv3 as well. If your device can be connected to the Internet (your hotspot at home is enough), you can use ssh to transfer the files to your device – like you do during development. The user name and password would again be specific to the device. Of course, you could also implement some mechanism for over-the-air updates. There are plenty of options.

Finally, you must provide a way to run the application linked against the new Qt version on the target device. This is easy, once your application and the Qt libraries are deployed properly on the device: Just power-cycle your device.

Of course, you must provide detailed descriptions about how to perform the previous steps.

Fulfilling the obligations of LGPLv3 is not that hard. Your developers already have all this infrastructure in place and use it on a daily basis. You just have to make it available to all the users of your devices – at least on request.

The main problem companies have with LGPLv3 is that they must provide users access to their devices. They claim that this access, although pretty restricted, poses a safety risk. A prime example are in-car infotainment systems, which use quite a lot of software under LGPLv2.1 including Qt.

Certainly, your infotainment system must not be able to control braking, accelerating or steering under any circumstances. In general, it must not have access to any safety-critical functions. But this requirement holds true for any infotainment system – including those not using LGPLv3 at all.

Your system should be partitioned into safe and unsafe execution zones. An application running in the unsafe zone like an infotainment system would never be able to access safety-critical functions running in the safe zone. This can be enforced by hardware features like ARM TrustZone. Even if your infotainment software ran with root privileges, ARM TrustZone wouldn’t give it access to safety-critical functions. You would have to break the strong encryption used by ARM TrustZone first.

In short, if your system uses safety-critical functions, it should be architected in such a way that it cannot abuse them – no matter whether you allow users to install some software on the device or not.

Anyway, installing software on a device is not much different to what is possible for smartphones through their app stores. I certainly don’t want an arbitray app to get access to my bank account, to my Amazon account or to my Music subscription. It is the job of Apple and Google to ensure this. Instead of forbidding third-party apps, both companies embrace third-party apps on their phones – and make a lot of money this way. Companies opposing LGPLv3 should turn around and see this as an opportunity for an app ecosystem. I think that consumers would benefit a lot.

References

Tags:

Leave a Reply

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