Discover more from Better Built By Burkhard
Episode 29: Better Built By Burkhard
Do You Have to Pay for Qt?
Do You Have to Pay for Qt?
I get about two calls and emails per month from agitated business owners, executives and managers that start like this:
“Last year, Qt Sales told us that we must buy a commercial Qt license. So, we bought a 5-year Qt license for €1,000,000. And, you tell us that we can use Qt for free. We feel cheated!”
“As a small business, we cannot afford paying €100,000 in advance for a 5-year Qt license.”
“Qt Sales told us that we must publish our source code if we use Qt under LGPLv3.”
“Qt Sales told us that we must allow our customers to install a modified Qt version on our harvesters. We can’t do this for safety reasons.”
This is all nonsense! No, you don’t have to pay for Qt. Like thousands of other companies, you can build the HMIs of your embedded devices with Qt under LGPLv3 - and don’t pay a single cent to The Qt Company. This includes HMIs for industrial machinery, cars, trucks, medical devices, home and professional appliances, TVs and STBs.
For B2B products, LGPLv3 stipulates the following obligations:
If you modified the Qt source code, you must highlight the modifications, e.g., by providing a diff between the original and modified versions (LGPLv3 §2).
You must show the texts of the LGPLv3 and GPLv3 and the copyright notices prominently in the GUI of your application, e.g., in the menu Settings | Licenses (LGPLv3 §4a, §4c) .
If you sell your product only to businesses - that is, not to private persons, then it’s a B2B product. Industrial, construction and agricultural machines, trucks, ships for commercial use, vending machines, ticket systems and professional appliances are clearly B2B products.
The LGPL defines a B2C product as a “consumer product […] normally used for personal, family or household purposes, or anything designed or sold for incorporation into a dwelling”. Hence, TVs, STBs, tablets, PCs, toys, virtual assistants, home appliances, home security cameras and cars are B2C products.
If you sell the same products for business and private use, the products are B2C products. If there’s doubt, then it’s a B2C product. For example:
If you sell the same security cameras both for office and home use, it’s a B2C product.
A mobile dialysis machine or an EEG headset that patients use at home is a B2C product. However, medical devices that are only used in and sold to hospitals and medical practices are B2B products.
The distinction between B2B and B2C products is important, because LGPLv3 requires an additional obligation from B2C products. For B2C products, you must provide the installation information, which allows users to install a modified version of the Qt libraries on the device (LGPLv3 §4e).
Users must be able to build a modified Qt version for the device, e.g., as part of your standard Yocto build. Then, they must be able to install the modified version on the device, e.g., by your normal update mechanism. As long as the modified Qt libraries are interface-compatible with the original Qt libraries, your applications must run with the modified Qt libraries. Your applications can be combined with the modified Qt libraries by shared linking, by static linking or any other way of making them run together (LGPLv3 §4d).
This LGPLv3 requirement is satisfied by the standard OTA update mechanism of your consumer device. You must only allow consumers to upload their modified Qt versions to an update server. If a consumer installs a modified Qt version, you have the right to void the warranty. You can even go a step further and forbid users to operate the device, e.g., forbid them to drive their cars on a road.
LGPLv3 allows you to keep the source code of your applications and libraries closed, although they use Qt under LGPLv3 (LGPLv3 §4): “You may convey a Combined Work under terms of your choice […]” Let me translate this legalese into normal language. Combined Work is the combination of your proprietary applications and libraries with the Qt libraries. You can release this combination under a license of your choice. Especially, your license can say that the sources of your applications and libraries are a secret.
By now, it should be clear that you can use Qt under LGPLv3, pay nothing to The Qt Company, do not have to publish your source code, and only have to enable the installation of a modified Qt version on B2C products but not on B2B products. Using Qt under LGPLv3 is a perfectly viable option for businesses. Actually, thousands of business do it.
Once you understand LGPLv3, the crucial question changes from “Do you have to pay for Qt?” to “When does your business benefit from paying for Qt?”. Now that is a good question! And - that is the question Qt Sales should answer.
My post Using Qt 5.15 and Qt 6 under LGPLv3 lists which Qt modules are available under LGPLv3 (green), under Qt Commercial (red) and under Qt Marketplace License (yellow). The red modules include Virtual Keyboard, Wayland Compositor, Quick 3D, WebAssembly, Qt for MCU and Safe Renderer. For each red module determine whether you need it, what the alternatives are and how long it would take to implement or integrate the alternative.
This gives you the costs for using Qt under LGPLv3. Compare these costs with the costs for Qt Commercial and then make an objective business decision. This is a good topic for another episode of my newsletter 😉
By the way, I work out such cost comparisons with my customers, educate them about FOSS licenses, and access their license situation in my service offering Checking License Compliance. You can gain a lot of this information from my talk Using Qt under LGPLv3 - for free.
Peter Schneider, Senior Product Manager at The Qt Company, tries a cost comparison between Qt Commercial and Qt LGPLv3. Using the same alternative facts about LGPLv3 as his sales colleagues, he concludes that the total cost for an embedded system using Qt LGPLv3 is higher than for one using Qt Commercial. I debunk his “arguments” in my critique.
With a little change in the system architecture, the parking experience at Munich Airport would turn from awful to good. All the pieces are in place but they don’t interact in the right way.
I show how to use the Structurizr tool to draw context and container diagrams for a harvester terminal. Simon Brown’s C4 models are an excellent way to visualise architecture on system, application, component and code level.
Around the Web
A static analysis tool spits out 15,000 issues for your code base and tells you that it takes roughly 10 person years to fix them all. This information is useless. Adam Tornhill makes the information useful by ranking the issues by how often the code around the issue changes. The more often the code changes the more important the issue is.
Adam has built the tool CodeScene that combines information from multiple sources like static analysis tools, GitHub, Jenkins and JIRA to come up with the ranking. You may also be interested in Adam’s book Software Design X-Rays: Fix Technical Debt with Behavorial Code Analysis.
The problem with SAFe is too much bureaucracy and trying to solve an inherently non-deterministic problem (software development) with a deterministic plan:
“Five 2-week sprints with processes to align dependencies is just a waterfall Gantt chart. It fails for the same reason waterfall and all fake agile fail, it assumes things will turn out as planned.”
As SAFe didn’t yield the promised improvements after some years, upper management gave the development teams (emphasis mine)
[…] free rein to solve the problem and air cover to clear roadblocks. Our solution? “We need to implement continuous delivery and we need to go to production daily.” We re-architected the teams into product teams to mirror the application architecture we wanted. We converted hard dependencies to soft dependencies with a loosely coupled architecture built by teams formed around business domains.
That’s what I did with a customer this year. However, they are still clinging to SAFe. I am pretty sure that Continuous Delivery will soon sweep away SAFe.
The Innoficiency Principle states that innovation and efficiency are mutually opposable goals. In any reasonably functioning organization, one cannot be increased without decreasing the other.”
Apple is the prototypical example. It created the iPhone (innovation) and then perfected the production of iPhones (efficiency). There hasn’t been much innovation since the iPhone - just a lot of ruthless incrementalism.