Dear Reader,
You are the first to learn that I launched a new product: License Compliance for Embedded Linux Systems. Actually, it is not that new any more. I have performed license compliance checks for more than 25 customers over the last 5 years - but in some kind of stealth mode. Now, the product got its on own landing page with pricing, description and Q&A section.
When companies contact me, they feel that The Qt Company paints too rosy a picture about Qt Commercial and too dark a picture about Qt LGPL. I help them make an informed decision whether to choose Qt Commercial or Qt LGPL. Most of them find out that Qt LGPL is good enough for their embedded devices, that the obligations of the LGPL are easy to satisfy and - bonus - that the costs of Qt LGPL are much lower than those of Qt Commercial. Don’t forget that Qt LGPL is a fantastic product and that ten thousands of companies have built fantastic products with it.
As part of these engagement, I had to explain the Qt license agreement many times. You find my explanations of the darker parts of the Qt license agreement in this newsletter. I can only urge you to read the Qt license agreement very thoroughly, discuss it with other people and compare it with the LGPL - before you sign it.
Enjoy reading,
Burkhard
Do Not Sign the Qt License Agreement Unchanged
Qt sales will try to sell you the Qt for Device Creation (QtDC) license as the care-free option for using Qt on embedded devices. They will also portrait LGPL as a very dangerous and complicated license. I beg to differ - and so will almost all of my customers, readers and listeners.
The Qt license agreement is a masterpiece in legalese, vagueness, ambiguity and omission - with numerous pitfalls. The Qt Company has revised the agreement many times over the last years (just compare the current agreement with the 2021 agreement). The Qt Company has optimised the agreement such that Qt applications, which run on a PC and communicate with an embedded device without Qt, become embedded devices under the QtDC license.
Some years back, The Qt Company happily sold Qt for Application Development (QtAD) licenses to such customers. When these licenses come up for renewal, The Qt Company claims that these customers commit a material breach of the license agreement and try to force the much more expensive QtDC licenses on them. Some customers will cave in, some will figure out that Qt LGPL or abandoning Qt is a better option.
Other companies fall for the care-free nonsense from Qt sales and pay 6-digit euro license fees per year. Inevitably, they will find out that Qt LGPL would have be more than enough for their embedded devices. Guess how these companies will feel and what they will do at the end of the license term.
All these companies have in common that they didn’t read the Qt license agreement thoroughly and they didn’t evaluate alternatives to the QtDC license. They only have to blame themselves for their calamity. The Qt Company is in its full right to write their license agreement however they want - although the agreement is certainly not “cute”. Of course, potential Qt customers are also in their full right to demand changes to the license agreement or walk away.
I will point out the murkier parts of the Qt license agreement and suggest changes. I am skeptical that The Qt Company will accept these changes, but it’s worth a try. The way The Qt Company treats you in these negotiations will tell you a lot, whether you should sign the agreement or not. Knowing the alternatives to QtDC will improve your negotiation position considerably.
Nearly everything is an embedded device
Definition of “Devices”
The latest Qt Product and Service Agreement for the Qt Development Framework defines embedded devices as follows.
2.10. “Devices” shall mean
i. hardware devices or products that
a. are manufactured and/or distributed by the Customer, its Affiliates, Contractors or End Customer, and
b. incorporate, integrate or link to Applications such that substantial functionality of such unit, when used by an End User, is provided by Application(s) or otherwise depends on the Licensed Software; or
ii. Applications designed for the hardware devices specified in item (i).
Devices covered by this Appendix shall be specified in the Pricing Appendix or Purchase Document.
See definition 2.10 “Devices” in the Qt Product and Service Agreement for the Qt Development Framework (Version 2024-02, compliant with Qt Frame Agreement 2023-06 or later)
WTF!!!??? That was my first reaction, too. It’s a masterpiece in legalese: vague to the point of being incomprehensible and far too broad in its scope. Let me try to translate this mumbo jumbo into plain English.
The logical structure of the Device definition is: (i.a and i.b) or ii
. Your “hardware product” is considered a Device, if either clause (i) holds or clause (ii) holds. Clause (i) is satisfied, if and only both clause (a) and clause (b) are satisfied.
Devices according to Clause (i)
Let me start with a simple case. A manufacturer M of agricultural machines (the “Customer”) employs an in-house team to develop the machine’s driver terminals (the “units”, “hardware devices” or “hardware products”) with Qt. M sells its harvesters with the driver terminals to farmers F. The driver terminals are certainly Devices in the sense of the above definition, as M manufactures and distributes them (i.a) and one or more Qt applications (called Applications per Definition 2.3), which provide “substantial functionality” for the operation of the machine, run on the terminal (i.b).
Clause (i.a) significantly increases the number of devices and developers requiring licenses by including not only M but also its Affiliates, Contractors and End Customers.
Affiliates are companies, in which M has a controlling majority or which have a controlling majority in M (see definition 3.1 “Affiliate” in the Qt Frame Agreement). For example, one of the world’s biggest agricultural manufacturers, owns 20 brands. Each brand is regarded as an Affiliate.
If M shares substantial parts of the terminal’s software (including applications and libraries using Qt) with its Affiliates, M must also buy Qt Commercial licenses for the devices and developers of the Affiliates. The same holds for M’s business units.
For example, the tractors produced by the different brands of the above agricultural manufacturer might share large parts of the code of their driver terminals. Only the GUIs show a distinct branding. If one of these brands uses Qt Commercial, all the other brands have to use it, too.
Only if a brand can prove that it doesn’t share “substantial” code based on Qt with other brands, it can escape the Qt Commercial jail. Of course, The Qt Company will interpret “substantial” as “any code based on Qt”. Affiliates will have a hard time arguing that the use is not substantial. Their best course is not use Qt at all. Alternatively, M and all its Affiliate can change to Qt LGPL once the license period has expired.
If M outsources the hardware or software development of the driver terminals partially or completely to Contractors (see definition 3.2 “Contractor” in the Qt Frame Agreement), M must pay the per-device or per-developer fees for the Qt Commercial licenses. Especially, M must also buy developer licenses for all the Contractors developing Qt applications for M or its affiliates.
End Customers are companies to whom “[M], directly or indirectly, distributes copies of Redistributables as integrated or incorporated into Applications or Devices” (emphasis mine, see definition 2.4 “End Customer” in the Qt Product and Service Agreement for the Qt Development Framework).
I can think of one scenario why The Qt Company included indirect distribution to End Customers in their Device definition. M could use the Qt for Application Development (QtAD) for the development of terminal software and pay only for the per-developer licenses. M sells all of its terminals to a reseller, which is not an Affiliate. The reseller sells the terminals to the End Customers and licenses the Qt software under the LGPL. M and the reseller would save the per-device license fees. Of course, The Qt Company wants to close this loop hole.
Devices according to Clause (ii)
ii. Applications designed for the hardware devices specified in item (i).
Clause (i) covers Qt applications that run on embedded devices. Clause (ii) extends the definition of Devices to cases, where the Qt applications do not run on the Device but on a PC, phone or tablet and where Qt is not even installed on the device.
For example, a med-tech company MT builds and sells an X-ray scanner for humans, a typical embedded device. Qt is not installed on the scanner. Medical personnel use a Qt application running on a Windows PC to operate the scanner and to evaluate the 3D scans. The PC application and the scanner communicate over a LAN.
For The Qt Company, the PC application is an application designed for the scanner. Hence, the PC application and the scanner constitute a Device. MT must buy a Qt for Device Creation (QtDC) license and pay license fees for each developer and for each device. Buying only a QtAD license for developing the Qt application on the Windows PC is not enough.
I have seen The Qt Company apply this reasoning to many of my customers. The Qt Company even claimed that MT would violate the LGPL. Now, that is false! The LGPL considers the PC application and the embedded device as two independent units that are licensed separately.
Earlier versions of the Qt license agreement contained a clearer definition of clause (ii).
[Products are Devices] regardless of whether the Redistributables are distributed together with the hardware or not.
See “Devices” definition in the 2021 version of the Qt license agreement
The Qt usage reports still use this definition. Redistributables are the Qt libraries in object code form. In other words, it doesn’t matter whether the Qt application runs on the Device or not.
I’d like you to meet my pedantic German self, which helps a lot in dissecting contracts. I think that the setup of the med-tech company MT does not constitute a Device in the sense of the Qt license agreement. Clause (ii) refers to “hardware devices specified in item (i)”.
Remember that clause (i) is only satisfied if both clause (i.a) and clause (i.b) are satisfied. Clause (i.b), however, demands that the Qt applications run on the device. As Qt is not installed on the X-ray scanner, clause (i.b) is not satisfied. Hence, clause (i) is not satisfied. Hence, the X-ray scanner is not a device in the sense of the Qt license agreement. Hence, clause (ii) doesn’t apply.
The X-ray scanner would only be a Device, if a Qt application providing “substantial functionality for the device” would run on the Device. Then, clause (ii) would not matter anymore. But don’t get your hopes too high. In the end, a court would have to decide, as The Qt Company would still argue that MT’s setup is a Device. The formulation “Hardware devices or products that […] incorporate, integrate or link to [Qt] Applications” is vague enough to interpret it as follows: The Application can run either on the device or on a PC connected via a network “link”.
How to change the license agreement
It is safe to assume that most Qt customers don’t have enough negotiation power to change the Devices definition. However, the last sentence of the definition gives them an opening.
Devices covered by this Appendix shall be specified in the Pricing Appendix or Purchase Document.
Qt customers should insist that all the Devices covered by the license agreement are explicitly listed in the Pricing Appendix or Purchase Document. If a Device is not listed, the Qt license agreement (the “Appendix”) does not apply.
Qt customers should also add a list of their products - including the desktop and mobile Qt applications “designed” for embedded devices - that are not considered Devices. The med-tech company MT would add their PC application and their X-ray scanner to this list.
The modified last sentence of the Devices definition could be written as follows (changes in italics). The Customer’s lawyer should be able to come up with an acceptable formulation.
Devices covered by this Appendix and Devices not covered by this Appendix shall be specified in the Pricing Appendix or Purchase Document. During the License Term, the classification as Device or Not-Device can only be changed by mutual agreement of both Parties.
I would assume that The Qt Company would require an audit. The customer is free to allow or forbid the audit. I would expect that allowing the audit will increase the changes that The Qt Company signs the agreement. But it is entirely up to the customer.
Obviously, The Qt Company need not accept this change. Similarly, potential customers need not sign the unchanged agreement either. They can walk away and use Qt under LGPL or don’t use Qt at all. The Qt Company would lose a paying customer. There are good reasons for both parties to come to a mutual agreement.
Termination of the License Agreement
Reasons for termination or suspension
According to clause 11.1, The Qt Company has the right to terminate the license agreement, if the Customer “commits a material breach of the Agreement” or if the Customer “becomes bankrupt, insolvent or goes into liquidation or debt restructuring”. A material breach exists, for example, if the customer does not pay in time or not at all, if it sells more Devices than it has distribution licenses or if it fails to provide the usage reports requested by The Qt Company.
According to clause 11.2, The Qt Company can suspend the customer’s right to use Qt on its Devices or for Development. The Qt Company can, for example, forbid the customer to sell its devices, if the customer doesn’t remedy the violation or breach within 10 days after receiving a written notice from The Qt Company. The reasons for such a suspension go from concrete to vague (emphasis mine).
[The Qt Company can suspend the customer’s use of Qt] should Customer fail to make payment in timely fashion or otherwise violate or is reasonably suspected of violating its obligations under the Agreement and/or this Appendix […]
So, if The Qt Company “reasonably suspects” that a customer violates the Qt license agreement, it can forbid the customer to sell or operate its devices. What “reasonably” means is solely decided by The Qt Company - or by a court. However, the customer wouldn’t be allowed to operate its devices until the court decides. You know what customers would do in such situations. So, customers best avoid these situations.
My recommendation would be to remove the text in italics from clause 11.2:
[The Qt Company can suspend the customer’s use of Qt] should Customer fail to make payment in timely fashion or otherwise violate
or is reasonably suspected of violating its obligations underthe Agreement and/or this Appendix […]
With this change, suspecting a violation is not enough. The Qt Company would have to prove a violation or a material breach. A court could quickly lift an unfounded suspension.
Again, The Qt Company may accept this change or not. The customer can walk away or not.
Beware of auto-renewal
Welcome to the wonderful world of subscriptions, where you subscribe to videos, phones, Internet - and Qt. The License Term will automatically renew, unless the customer notifies The Qt Company in writing “no less than thirty (30) days before expiry of the respective License Term” (see clause 5.1.4). The two parties may agree about a typically longer notification period like 60 days in an amendment to the license agreement. By the way, The Company can terminate the agreement in the same way as the customer.
Clause 5.1.5 allows both parties to renegotiate the license fees before the renewal. However, the customer should agree on the new license fees before the notification period starts. Otherwise, The Qt Company can charge the “standard list pricing applicable at the commencement date of any such Renewal Term”. And we all know in which direction the prices will move.
I would recommend Qt customers
either to remove clauses 5.1.4 and 5.1.5 from the license agreement
or to notify The Qt Company about the termination one week after the License Term started.
This makes sure that the Qt subscription does not automatically renew.
Note: Cancelling the subscription in time is the only way to terminate the Qt license agreement for Qt customers.
Rights and duties upon termination
If Qt customers cancel the Qt subscription in time, they have certain rights and duties upon termination (see section 11.3).
Clause 11.3.1. The developers of the customer must stop using the Qt tools, Qt libraries, pre-built Boot2Qt images and all other Qt-ware that they downloaded and installed through the Qt Commercial license. They must start using Qt-ware under the open-source licenses: LGPL-3.0 for the libraries and GPL-3.0 for the tools.
Clause 11.3.2. The developers must also delete all installed copies of commercial Qt tools and Qt libraries. Qt customer can keep some developer licenses to continue the support of their End Customers. Bug fixing is OK. Adding new features is not OK.
Clause 11.3.3. “Distribution Licenses are perpetual”. Qt customers can use existing devices with Qt for Device Creation (QtDC). They can sell devices with QtDC until they have used up all the distribution licenses they have paid for.
Note: Customers lose the rights from section 11.3, if they committed a material breach of the license agreement.
If you read section 11.3 in the license agreement, you’ll find out that the customers’ duties have been specified pretty clearly, whereas the customers’ rights are more wishy-washy. My summary above is a reasonable interpretation - based on earlier and clearer versions of the Qt license agreement and on usual business practices.
I recommend Qt customers to make the formulations in section 11.3 clearer and more specific. For example, customers should specify how many developer licenses they may keep, for how long and for which purposes. They should also add that they can use up all the excess licenses they have paid for but not yet sold with their devices.
I haven't gotten all the way through this post, but love the top. Railed against the "Everybody Must Buy a License" definition of "OpenSource" for many years. I think you forgot to mention that commercial customers are paying hundreds of thousands of U.S. dollars for a "product" that has a bug database north of 31K open bugs. Some of them are old enough to vote in America (18), many are old enough to drive (16 years) and some might even be old enough to drink (21).
Recently I forked CopperSpice (which is itself a fork of the last real OpenSource Qt 4.8.x). Had high hopes for that project, but it totally lost its way. For now the fork is LsCs https://lscs-software.com/ somewhere between replacing all of the platform plugins with GLFW and the replacing of Webkit with Servo, it will move to source forge and change its name. https://basisdoctrina.com/ There will be no QML. Just dropping that failed experiment gets rid of a trainload of bugs. Another large source of Qt bugs is the legacy platform plugns. Because of the "Everybody must buy a license" definition of "OpenSource" that Qtc has, too few developers utilize the product to find bugs . . . not that Qtc is going to bother to fix them. GLFW has a large developer base and straddles all important non-phone embedded systems as well as major desktop platforms.