We often get asked about Qt licensing, so here is my personal take/explanation on the whole commercial vs open-source issue. Just my opinion – does not constitute legal advice or company policy…
Can I use the open-source Qt license in a commercial project?
Many of our customers use Qt, which is a great product for embedded GUI creation, and indeed we supply Qt-ready ARM Linux builds to help them. Some customers use “commercial” Qt and thus pay the Qt Company per run-time license, and some use the open-source version and don’t pay. Because we are engineers, we tend to shy away from asking our customers about this choice, and certainly avoid giving advice. But, also because we are engineers, we like to understand everything in our world. So this article is just my personal attempt to understand this issue.
Before getting into the licensing side of things, I want to make clear my view that it makes good sense to use commercial products for “real” projects where possible. This pays for professional support, which can be vital when there are deadlines to meet, and also IP indemnity, which means you don’t have to worry about who owns all the code you are using, because you bought the rights to it in a commercial transaction, and the seller is therefore liable. This has been a historical advantage of the likes of Windows CE over Linux.
But if you are already using Linux, you have already come down on one side of this argument. So the question around licensing of products such as Qt comes down to whether one would use the commercial license because of the associated benefits, or whether it’s because to all intents and purposes you have no choice because of license restrictions. That’s the question I want to answer.
GPL vs LGPL and Tivoization
Open-source Qt can be licensed under either GPL (General Public License) v2/v3 or LGPLv3. What does this mean?
GPL-licensing on the face of it seems pretty useless for commercial products, as it requires you to deliver full-source code to the end user. Fine for the OS, but not for your precious application. But fortunately it’s not as simple as that.
If you think about it, open source-code gives you two problems. One, which I will call “Source Publication”, is that anyone, including competitors, can look at your code and benefit from it as they wish (within the restrictions of the GPL of course). The other is that anyone can modify the source code (or entirely replace it with some other source code) and run it on your product, thus changing the function in any way they choose – I’ll call this “Device Vulnerability”.
You might have heard of “Tivoization”. In 2006 a company called TiVo created a Linux-based set-top box. They apparently complied with the GPL, but arranged it so that their hardware would only run a digitally signed version of the firmware, thus denying the opportunity to modify functionality and so removing Device Vulnerability. This apparent loophole was closed by GPLv3, which explicitly forbade Tivoization for the “User Product”. So a futre consumer product licensing open-source software under GPLv3 could not be protected in this way against Device Vulnerability.
Moving to the issue of Source Publication, that is specifically, deliberately removed under LGPL (“Lesser” GPL), providing certain conditions are met. LGPL allows you to have a binary application, as long as it is dynamically (in the sense of at run-time) linked. Qt is available under LGPLv3 so that half of the problem is solved.
Maybe good news then, but that brings us right back to Device Vulnerability? Remember that GPLv3 explicitly removed the right to prevent this? Well, as you might guess, the v3 part of LGPLv3 has exactly the same implication. Quoting from GPLv3 sections which are explicitly adopted by LGPLv3:
the Corresponding Source […] must be accompanied by the Installation Information. […] “Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made[…]
Pretty clear. BUT, fortunately for embedded industrial developers wanting to use LGPLv3 licensed software, the definition of “User Product” comes to our rescue:
A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling[…]
So, in the case of Direct Insight’s customers, other than the small proportion who are concerned with IoT products which might have a home-user application, the Tivoization restriction doesn’t apply. In practice this means that for a typical i.MX6 module-based project, we can use the i.MX6 Secure Boot facility to prevent Device Vulnerability by creating a signed image, with the signature blown into unreadable hardware fuses while complying with LGPLv3. Additionally, Source Publication as noted above, is not required by LGPLv3 under specific technical conditions which we can also arrange to meet.
The Qt website says quite correctly that you can’t use the LGPLv3 version to create “closed consumer devices”, which is quite true. But, in my personal opinion as expressed above – and I am not a lawyer – you can create “closed industrial devices” or indeed “closed B2B devices” of most types. Again, I am not recommending that you do so – there is a lot of benefit to using the commercial version of Qt, but I hope I have explained how you can choose that option for positive, informed reasons, rather than feeling you are otherwise treading into a grey area where you might be contravening open-source license conditions.