The post Guide to the Total Cost of Ownership of Open-Source Software by Peter Schneider (The Qt Company) provides a smorgasbord of alternative facts why we should not use Qt LGPL but instead buy Qt Commercial. I can’t miss the irony that Schneider like many of his sales colleagues are bad-mouthing Qt LGPL to promote Qt Commercial. Qt LGPL and Commercial share the same code.
Why Qt LGPLv3 is Not More Expensive Than Qt Commercial
In the section “The Myth of Open Source is Free”, Schneider outlines the four “guidelines” of his post and makes his main claim (emphasis mine).
While the use of commercial software includes little hidden costs over the product’s lifetime, several additional costs must be considered when using open-source libraries. These include:Peter Schneider
1. Fixing bugs yourself […]
2. Implementing the open-source obligations […]
3. Implementing legal checks […]
4. Performing regular license compliance checks […]
Bollocks! The costs are pretty much the same – no matter whether we use Qt LGPL or Qt Commercial for building embedded systems. I’ll focus on embedded Linux systems in my critique, because they are prevalent in most industries. My arguments are transferable to embedded systems running on real-time operating systems or bare metal, to desktop applications and to mobile applications.
When it comes to license compliance, we must look at the whole system, not just one library. A typical embedded Linux system includes 300-500 packages providing several tools, libraries and configuration files. Most of these packages are under a FOSS licenses (e.g., MIT, BSD, LGPL, GPL) or a combination of FOSS licenses. Very few are under a commercial license. Qt is the prime example. Qt is triple-licensed: Commercial, LGPLv3 and GPLv3.
When it releases an embedded device, a company must comply with the license obligations of all packages – no matter whether a package is under a FOSS or commercial license. The company incurs the costs for a license compliance check anyway. The license costs for Qt Commercial come on top.
Let me refute Schneider’s “guidelines” one by one.
Fixing bugs yourself
Fixing bugs takes time. Every software has bugs, whether it uses open source or not. The question is only who fixes the bug. If one buys commercially supported software libraries, the code maintainer does the bug fixing. If one uses open-source, then one can hope that the bug is fixed in the open-source community by somebody else.Peter Schneider
Schneider argues that fixing bugs in free open-source software (FOSS) has a higher cost than in commercial software – for companies building embedded systems. This is disputable – to say the least. In general, I have found the developers of FOSS incredibly responsive. I have often got bug fixes within hours. Moreover, I have rarely found showstoppers in FOSS – certainly not more than in Qt.
Paying for Qt Commercial doesn’t guarantee us in any way that The Qt Company fixes our bugs. Even paying Qt customers must often fix their bugs themselves or find someone who does it for them. Fortunately, Qt is open-source so that they are able to do so. The same goes for all the other free open-source software. We are not at the mercy of a commercial software vendor. That’s true freedom – and invaluable!
Nothing of the above is the real point. The point is that Schneider compares apples with horses. He claims to look at the total cost of ownership. Then, he should look at the embedded Linux system as a whole. If he did, he would detect that the effort for fixing bugs is the same for a system with Qt Commercial and for a system with Qt LGPLv3. Qt LGPLv3 shares the source code with Qt Commercial. A comparison between Qt Commercial and Qt LGPLv3 doesn’t make much sense, now does it?
Implementing the open-source obligations
Schneider creates smoke and mirrors about open-source license obligations. He lists four “typical responsibilities of the open-source software user”. These four responsibilities are only “typical” for software under LGPLv3 on a consumer device, that is, for consumer applications written with Qt LGPLv3 (e.g., TVs, STBs, cars, home appliances). Of course, he mixes in some fear about GPL. But let us take his points step by step – for an application using Qt LGPLv3.
- An application using Qt LGPLv3 must prominently display in its GUI that it uses Qt LGPLv3 (LGPLv3 (4a)) and must display the license and copyright texts of both LGPLv3 and GPLv3 (LGPLv3 (4c)). In my talk Using Qt under LGPLv3 (slides 9-11), I show how such a GUI could look like. The implementation took me half a day. The GUI reads the license and copyright texts from a directory structure that reflects the menu structure.
- The company releasing the application must make the source code of the used Qt libraries available, e.g. for download from a web server or on a DVD. It is not enough to provide a link to download.qt.io. At this point, Schneider furtively moves from LGPL to GPL (emphasis mine): “[Users of the application] can inspect and download the open-source code, depending on the open-source license sometimes even your own code“.
To be very clear: We must only release the source code of a proprietary application, if the application links against any library licensed under GPL – no matter whether we use Qt LGPL or Qt Commercial. In other words: We must not publish the application source code if the application uses Qt LGPLv3.
- Both Yocto and Buildroot write the license texts, copyright texts and source files into a directory for each package. From this directory structure, we can create a compliance archive that we give to the users of our embedded device. The archive contains all the information to satisfy the license obligations. We use this directory structure to display the license and copyright texts in the GUI and to generate a license summary (e.g., as an Excel table). We can automate this process within a day and create all this information for every release in zero time.
- Schneider’s version of the anti-tivoisation clause reads like this (emphasis mine): “Users of your product need to be able to modify an open-source library on the device“. This is only true for “User products” or B2C products (GPLv3 (6)) like phones, TVs, STBs, home appliances, cars and medical devices used at home. This is not true for B2B products (see slide 12 of my talk Using Qt under LGPLv3). We don’t have to provide the Installation Information (anything required to build a modified Qt version, install and execute it on the device) for B2B products like tractors, excavators, trucks, professional appliances and medical devices used in hospitals or in medical practices. That’s why the majority of manufacturers of industrial machinery chooses Qt LGPLv3.
Providing the Installation Information is straightforward, because it exists already (see slides 13-14 of my talk Using Qt under LGPLv3). Users can use the same SDK developers use to build the application. They use the normal way to update their embedded device: e.g., OTA update or update from a USB drive. When a device detects Qt libraries built and installed by a user, we can void the warranty or even revoke the permission of the car to drive on the road. Some of the world’s largest car and home-appliance makers have no problem using Qt LGPLv3.
Obligation 1 is specific to LGPLv3. Obligation 4 is specific to GPLv3 and LGPLv3 on consumer devices (excluding B2B devices). Obligation 2 – providing the source code – is not a must for permissive licenses (e.g., MIT, BSD). The Qt libraries are pretty much the only libraries on embedded Linux systems that are licensed under LGPLv3 only. Other LGPL libraries are licensed under LGPL2 (version 2 only), LGPL2+ (version 2 or later), LGPL2.1 (version 2.1 only), LGPL2.1+ (version 2.1 or later). So, the above obligations apply to less than 5% of the packages of a typical embedded Linux system.
The Qt Commercial license comes with its own obligations – besides the financial obligations. The typical Qt license agreement decrees:
- An application built with Qt Commercial must not use, combine, incorporate, link or integrate with any software using Qt LGPLv3. For example: The application using Qt Commercial must not communicate with another application using Qt LGPLv3, say, over Qt Remote Objects, DBUS or MQTT.
- We must not use Qt Commercial software to create software using Qt LGPLv3. For example: We must not cross-build the application against a commercial Qt SDK on the PC and run it on the device with Qt LGPLv3. Separating Qt Commercial and Qt LGPLv3 can be tricky for developers, if they build the current product in a product line with Qt Commercial and the next product with Qt LGPLv3. We can even switch from Qt Commercial to Qt LGPLv3 from one release to the next. Of course, we must honour the obligations from the Qt license agreement, which typically runs for 3-5 years.
Implementing legal checks
Schneider wants to make us believe that we need a legal check by a costly lawyer only for free open-source software. That’s pretty unlikely. Every respectable company has its legal department check commercial license agreements. I know that the Qt license agreement is at least as difficult to understand as the LGPLv3 and GPLv3. I have read all three license texts many times.
The purchasing department additionally has several rounds of negotiating the price. Qt licensees must pay the distribution licenses (royalties) quarterly and must prove how many units they have produced. The Qt Company even has the right to perform an audit.
For my own license compliance work, I have hired a lawyer once for two hours. I had the lawyer clarify my understanding about the Installation Information and some other terms of the (L)GPLv3. By the way, expert lawyers in FOSS licenses and intellectual property rights (IPR) cost more like 3000-4000 USD per day.
Taking all this into consideration, it’s fair to say that the legal costs for Qt LGPLv3 are not higher than those for Qt Commercial. If we must pay a lawyer to check the licenses of packages other than the Qt packages, we incur these costs no matter whether we use Qt Commercial or Qt LGPLv3.
Performing regular license compliance checks
Schneider pretends – again – that we need not perform the license compliance check for all 300-500 packages of an embedded Linux system, if we use Qt Commercial. That’s nonsense no matter how often he repeats this claim. Even with Qt Commercial,
- we must find the one library under GPLv3 that is linked indirectly to our application.
- we must find the one library under EPL (Eclipse Plugin Library) that is linked to our application and that must not be combined with libraries under LGPL2+, Apache 2.0 or MPL 2.0.
- we must comply with the license obligations of each package – no matter whether it is under commercial or FOSS license.
I am not aware that The Qt Company indemnifies Qt Commercial licensees against license violations by third-party libraries. The companies selling automatic license checkers don’t do it either. Not even the TÜV Süd does it. Nobody does it. It is far too easy to overlook a tiny detail. For example, a multimedia package includes source code under GPL depending on a build switch. Most BSPs set the switch so that the GPLed code is included.
Schneider sums up the four individual positions to come up with the total cost of ownership of using open-source software: 135,498 USD over five years. Of course, he forgets to add the fees for Qt Commercial on top. The result is meaningless, as he doesn’t look at the complete system and as he constantly moves the goal posts of the comparison. The whole post is a thinly veiled pitch to make Qt LGPLv3 look bad and expensive compared to Qt Commercial. The irony is that Qt LGPLv3 shares its code with Qt Commercial.
I perform license compliance checks of embedded Linux systems as a side business. I charge roughly 25,000 EUR as a one-off price for the complete compliance check. My customers get a compliance archive containing all the license texts, copyright notices and source packages required to comply with the licenses of the 300-500 packages. They get a database with the compliance results for 500+ packages. They also get the QML code to display the licenses in their GUIs. And they get a training to do the compliance checks on their own.
They must update my initial compliance check for every release. In the worst case, they find 3-5 packages with different licensing. They can check these packages easily within half a day. Assuming that they do four releases per year, they look at 2 days per year. At an hourly rate of 100 EUR, the yearly costs are 1,600 EUR. Over five years, these companies spend something like 33,000 EUR.
Note that they spend 33,000 EUR no matter whether they use Qt Commercial or Qt LGPLv3. The costs for Qt Commercial come on top. With 3 developers and 1000 units per year, you easily look at 100,000+ EUR per year (see my post Using Qt 5.15 and Qt 6 under LGPLv3 for more details).
Hello, and thank you for the thorough analysis of my blog post. You might be surprised that I agree with most of your statements, IF, and that’s a big IF, the blog post would have compared Qt’s dual licensing options. As the title states, the blog post is about the TCO of open source and not a financial comparison between open source and commercial options. It’s neither about analyzing Qt in particular but the TCO of open source use in general. Yes, I use Qt as means for several example calculations, but I do not in all dimensions. I agree that using commercial software also comes with obligations, risks, and legal checks. But the blog post is not about the TCO of commercial software. I think I should have been more precise when it comes to writing about “additional costs must be considered when using open source…” that the “additional” refers to zero acquisition costs of open source and not “additional” to using a commercial license. I guess I should have been more apparent here. My mistake. Anyway, this is a good and important discussion on this topic. I feel however that you disregarded my statement: “The guide is written in such a format that it demonstrates the total cost of open-source based on examples. It’s easy to adjust the TCO calculation with your input values. The focus of this guide is on explaining the cost components and not on any individual results.” Well, anyway, as said, you make great points on the topic of Qt’s dual licensing. Until we get a chance to talk in person… Peter
Great post, thank you very much for this timely information.