Episode 34: Better Built By Burkhard
Illegal License Combinations
Typical Software S (proprietary or not) - an application or a library - links against several other libraries L1, L2, …, Ln. A license compliance check
determines the actual license for each component S, L1, L2, …, Ln, and
whether the combination of the licenses of all components S, L1, L2, …, Ln is legal and desirable.
The table shows the resulting license of combining two libraries or an application with a library.
TLDR:
If any two libraries are licensed under incompatible licenses (marked by XXX in the table), the combined work of your software and the libraries violates at least one license. You must not deploy the combined work.
If any library is under GPL, the combined work is under GPL and you must publish the source code of your proprietary software. For businesses, this result is typically undesirable.
Let me give you some examples. You want to license the application S under a commercial license (S$$$, for short). The libraries come under different FOSS licenses.
Example 1: Application with Qt Libraries under LGPL-3.0
Let L1 be under BSD-3, L2 under Apache-2.0 and L3 under LGPL-3.0. The combination of S with L1, L2 and L3 is under S$$$.
BSD-3 * Apache-2.0 * LGPL-3.0 * S$$$ =
Apache-2.0 * LGPL-3.0 * S$$$ =
LGPL-3.0 * S$$$ =
S$$$This is the classic example of a proprietary application linking against Qt libraries under LGPL-3.0 and some other libraries under other compatible licenses.
Example 2: Illegal Combination of Apache-2.0 and LGPL-2.1-only
Let L1 be under BSD-3, L2 under Apache-2.0 and L3 under LGPL-2.1-only. The combination of S with L1, L2 and L3 is illegal.
BSD-3 * Apache-2.0 * LGPL-2.1-only * S$$$ =
Apache-2.0 * LGPL-2.1-only * S$$$ =
XXX * S$$$ =
XXXIf you modify or extend software licensed under Apache-2.0, you can put your changes under any license terms (see section 4. Redistribution). This sublicensing allows you to keep patent rights for your changes. GPL-2.0, LGPL-2.0 and LGPL-2.1 forbid this explicitly. The preamble of GPL-2.0 makes this very clear: “[…] any patent must be licensed for everyone's free use or not licensed at all” (see also paragraph 7). LGPL-2.0 and LGPL-2.1 have similar clauses (search for “patent”).
If library L3 were licensed under LGPL-2.1-or-later, the combination would be perfectly OK. You could license L3 under LGPL-3.0, which is included by the “or-later” part. This license combination is shown in Example 1 above.
In my license compliance checks, I have come across the illegal combination of Apache-2.0 and LGPL-2.1-only libraries a couple of times. The most prominent example for this license violation is Qt WebEngine.
Qt WebEngine uses more than 200 components under different licenses. It uses 60 components under Apache-2.0 and 13 under LGPL-2.1. A detailed analysis reveals that 11 of the 13 components are licensed under LGPL-2.1-or-later and the remaining two - hunspell and hyphenation-patterns - under LGPL-2.1-only. Consequently, your applications and libraries must not use Qt WebEngine in the default configuration - no matter whether you use Qt Commercial or Qt LGPL-3.0.
Example 3: Illegal Combinations with EPL
Let L1 be under BSD-3, L2 under EPL (Eclipse Public License) and L3 under LGPL-3.0. The combination of S with L1, L2 and L3 is illegal.
BSD-3 * EPL * LGPL-3.0 * S$$$ =
EPL * LGPL-3.0 * S$$$ =
XXX * S$$$ =
XXXThe EPL requires that work combined of EPL and LGPL-3.0 parts must be licensed under EPL (see clause 3.2). The LGPL-3.0, however, requires that such combined work must be licensed under LGPL-3.0. All copyleft licenses in all versions - that is, LGPL-2.0, LGPL-2.1, LGPL-3.0, GPL-2.0, GPL-3.0 and MPL-2.0 (Mozilla Public License) - require the same. Hence, the combination of EPL with any copyleft license is illegal.
By the way, EPL software must not be combined with Qt libraries under Qt Commercial. Many Qt libraries like Qt WebEngine and Qt Multimedia link against libraries under LGPL. In short, EPL software can only be combined with software under permissive licenses like BSD and MIT.
The Paho and Mosquitto MQTT client libraries are licensed under EPL. You must not use these libraries as a replacement for the commercial-only Qt MQTT module, if you use Qt LGPL-3.0. The mqtt_cpp client library comes under the permissive BSL-1.0 (Boost Software License) and could be a viable alternative to Qt MQTT.
Example 4: Undesirable Combinations with GPL
Let L1 be under GPL-3.0, L2 under MIT and L3 under LGPL-3.0. The combination of S with L1, L2 and L3 is under GPL-3.0.
GPL-3.0 * MIT * LGPL-3.0 * S$$$ =
GPL-3.0 * LGPL-3.0 * S$$$ =
GPL-3.0 * S$$$ =
GPL-3.0The combined work must be licensed under GPL-3.0. Your proprietary software must be licensed under GPL-3.0, too. Therefore, you must make the source code of your proprietary software publicly available. The result is the same, if you replace LGPL-3.0 by Qt-Commercial. The combined work is under GPL-3.0, too.
For businesses, this is normally undesirable, because software is a competitive advantage. For universities and government agencies, this is often OK or even required.
The combined work is under GPL, if a single file used by any of the libraries or by the software itself is under GPL. This can easily be overlooked. The ffmpeg package, for example, has a configuration switch —enable-gpl, which adds some libraries under GPL. Many BSPs explicitly add the switch in the build recipes. If, say, your software uses Qt Multimedia with the ffmpeg backend (the default from Qt 6.5) or uses the ffmpeg libraries directly, your software will be under GPL - with all its consequences.
My Content
Using Qt 6 under LGPLv3
The Qt Company changed the commercial licensing in February 2022. So, it was high time to update my post on Qt licensing.
It’s the best and most comprehensive [article] I’ve seen on Qt and licenses!”
Please accept my deepest thanks for such a valuable contribution!
Carlos Almeida Jr.
You are welcome, Carlos 🙏 Many other people have told me the same in private conversations. Hence, the predecessor post has turned license compliance checks of embedded Linux systems into a lucrative side business for me. I have put a lot of time and effort into the new post to make it even better. Here are some teasers.
Qt WebEngine uses an illegal combination of libraries. It must not be released in any configuration, where Apache-2.0 libraries are combined with the two LGPL-2.1-only libraries hunspell and hyphenation-patterns. This is true for all Qt licenses, commercial or not.
The crucial definitions of “Prohibited Combination” and “Permitted Software” in the Qt License Agreement contradict each other. Therefore, both clauses are void. My recommendation: Do not sign the license agreement! Let The Qt Company rewrite it or walk away.
The definition of “Prohibited Combination” is so vague that an application using Qt for Device Creation must not communicate with any other application using Qt LGPL-3.0, if the applications run on the same embedded device. This is more restrictive than GPL.
You must not release software, which a contractor developed using QtCreator under GPL and the Qt libraries under LGPL-3.0, with commercial Qt libraries.
I outline a procedure how to decide whether Qt for Device Creation is worth its money or whether you should go with Qt LGPL-3.0. You can make an informed business decision.
Talk: Using Qt under LGPLv3
In my talk from Qt Day Italy 2019, I explain
how to satisfy the obligations of LGPL-3.0,
how license compliance differs for B2C and B2B products,
how to debunk some “alternative facts” about LGPL-3.0, and
how to check an embedded Linux system for license compliance.
The talk complements my long post Using Qt 6 under LGPLv3 (see above for a summary) with detailed information about LGPL-3.0.
Introduction to the SAE J1939 Standard
The J1939 standard makes ECUs from different manufacturers understand each other. It allows implements from one manufacturer to talk to tractors from many different manufacturers. It gives meaning to the bits in the ID and payload of CAN frames. Qt 6.5 introduces several classes (see my summary below) to decode and encode CAN and hence J1939 messages.
Around the Web
What’s New in Qt 6.5: New CanBus Classes
Qt 6.5, which is scheduled for release in March or April 2023, will see some useful improvements of the Qt CanBus library. Qt CanBus gains support for encoding and decoding CAN messages.
QCanFrameProcessor decodes a QCanBusFrame into a unique message ID and a map of signal values with parseFrame(). It encodes a unique message ID and a map of signal values into a QCanBusFrame with prepareFrame().
The class QCanMessageDescription holds a unique ID and a list of QCanSignalDescriptions. The unique ID identifies a QCanUniqueIdDescription object.
You define the bits of the frame ID making up the unique message ID with the class QCanUniqueIdDescription. For a J1939 message, the ID is the PGN, which spans 18 bits starting at bit 8.
You define the bit ranges of the signal values in the payload of the CAN frame with the class QCanSignalDescription. In the J1939 message EEC1, the signal value for the engine speed spans 16 bits starting at bit 24, is scaled by the factor 0.125, has a minimum value of 0 and a maximum value of 8031.875, and has the unit “rpm”. QCanSignalDescription provides setters and getters for all these properties.
Ken Tindell: Defending the CAN bus
Controller Area Networks (CANs, for short) have notoriously bad security. In the last 10 years, I have built four CAN-connected driver terminals: None of the CANs had any protection (except for obscurity). Once you can send messages on the CAN, you stop the brakes or steering from working fairly easily.
Ken Tindell has a very instructive 4-part video series how to defend the CAN bus against attacks. You can try out all the attacks with the free and open-source CANHack Toolkit provided by Tindell’s company, Canis Automotive Labs.
Junko Yoshida: IoT is Broken: It Won’t Scale
Security, interoperability and scalability are the IoT industry’s three-headed monster. After two decades of dithering, developers needs to define commonalities among siloed products. It must overcome a stasis in which everybody’s fixing the same problem but nobody’s doing it very well.
[…] IoT remains a fragmented market full of vertically structured embedded systems […] The result is a hodgepodge of embedded devices connected to the Internet, pitched as “smart” and lumped under a still vague rubric: IoT.
Junko Yoshida, IoT is Broken: It Won’t Scale, The Ojo-Yoshida Report
That’s exactly my experience. Each of my customers must develop some or all of these solutions: customised Linux image and SDK with Yocto, fast boot, secure boot, window and application manager, OTA updates, remote support, secure, fast or safety-critical communication with the machine, secure communication with the IoT cloud, and many more.
I argued in an earlier newsletter that the BSP is not enough and that the SoC or SoM manufacturers should provide these solutions out of the box. However, I don’t see the silicon manufacturers stepping up to this challenge. Yoshida could be right that the IoT market needs the introduction of something like Android, which turned the many vertical markets in the mobile phone market into a horizontal market - with the notable exception of iOS.
Yoshisha talked with Ian Drew, the chairman of Foundries.io, how to break up the walled gardens of IoT devices. Drew proposes a “comprehensive, secure and over-the-air, updatable Linux-based platform for development, deployment, and lifetime maintenance of IoT and edge devices.” I agree with Drew’s statement that the “differences between a medical device, a head unit of a car, a robot or a smart factory […] are actually quite small”. The Key Benefits to FoundriesFactory are convincing to me.