Is distribution licensing cost really that huge for low volume embedded devices?
-
Hi lovely qt people.
I'm developing an embedded device to be sold in very low quantities (10-100/year) at around £500/device.
This is my first foray into commercialising something I've made for myself, so it's purely a spare-time experiment at this stage. I don't really know if I'll sell any, and what the device's sales lifetime is.
So I was fairly shocked when I was told that the only way I could distribute the devices was if I purchased a 100 unit distro licence for 7246EUR before shipping the 1st unit.
That's on top of the annual small business dev license @ 499/year.In the worst case scenario this experiment would cost me nearly 7000EUR on unused licensing if it was to be a failure commercially.
I've been in contact with a Qt sales rep over email who have now stopped responding to me, so I'm trying to find answers here.
The cost seems a bit crazy to me, since all I'm doing is shipping a Yocto-qt5 meta layer on my device.
So I suppose I'm asking: Is this correct?
Is there a way to reduce the cost of the distro licence?
Or is Qt just not targeted at makers?It would be a shame to dump Qt after about a year of development time into the hardware & teaching myself Qt.
Especially since for HMI purposes, ST's TouchGFX is great and free in every sense of the word. (I appreciate, it's apples/oranges, but for my application it would suffice with some compromises).Thank you for any help guys.
-
You're welcome; I'm happy to share what I understand. For simplicity, I'll only discuss Qt 5.12 LTS with 3 license options (GPLv3, LGPLv3, and the commercial license).
Disclaimers:
- This is a simplified, illustrative, and incomplete overview. It aims to help readers to start to understand certain licenses, but readers must still delve deeper to fill in the gaps.
- There is no guarantee that lawyers, judges, the Qt Company, or the Free Software Foundation will agree with my post.
A brief overview of the GPL family
I have looked into the open source licensing model before, but even after many questions, webinars & research I feel completely lost trying to grasp the possibilities/rights/obligations of LGPL/GPL.
I believe that many people are used to thinking of licenses in terms of pricing and restrictions ("How much does this software cost? How many people are allowed to use this software simultaneously when I buy this tier?"). The GPL family can feel foreign because it is primarily concerned with the freedom to run, study, modify, and share code instead of pricing arrangements.
In the beginning, there was proprietary software. Users of proprietary software often have no right to even view the source code, much less modify the code (to apply their own bugfixes/improvements) or share the code with their peers. The GPL was created to guarantee these rights to users. When someone releases software under the GPL, they're basically saying, "I give you the freedom to study my software's source code and modify it to your heart's content. I give you the freedom to share my code with whomever you please. I give you the freedom to incorporate my software into your own software. In return, you agree to offer all the same freedoms to your users by releasing your software under the GPL too."
Many companies could not accept the GPL model, so the LGPL was created as a compromise. When someone releases software under the LGPL, they're basically saying, "I give you the freedoms offered by the GPL. However, when you incorporate my software into your software, you're not obliged to pass on the full set of freedoms to your users -- you just need to offer those freedoms on my part of the software; you're free to license your other parts as you please."
Applying this to general embedded projects that use Qt 5.12
Most of Qt 5.12 is triple-licensed. That means you can choose to use Qt 5.12 under the commercial license, or the LGPLv3 license, or the GPLv3 license.
If you use Qt under (L)GPL, you are must give your end-users the right to study and modify source code.
- If you use Qt under the LGPL, your end-users must be able to replace the Qt libraries with a version of their choice. Your device must continue to function after they perform the replacement (unless Qt itself broke compatibility with your original version). You must provide your end-users a copy of the Qt source code or make it clear to them that you will supply the Qt source code upon request.
- If you use Qt under the GPL, you must do everything you'd do under LGPL, PLUS you must also offer the same freedoms to all of your code that won't work without Qt. (In other words, you give your customers the freedom to modify and rebuild your code)
In addition, if you use Qt under (L)GPL, you must:
- Make it clear to your users that your device uses Qt.
- Provide a copy of the (L)GPL license to your users.
- Publish any changes that you've made to the Qt source code.
If you use Qt under the commercial license, you don't have to offer any of the above. Instead, you must:
- Pay the Qt Company the fees as specified in the license
- (For small businesses) Allow your finances to be audited
- Take care not to mix software you've developed under commercial Qt with software that you've developed under open source Qt
- Forbid your users from modifying and sharing Qt and your software
(Note: The lists in this section are not exhaustive)
How does static/dynamic linking fit into the picture?
Where is the cut off for paying the the discribution license? When I compile my Qt app for Arm? Whether I link statically or dynamically it doesn't really matter, and I think dynamic linking would mean that I'm licence-free. Is this right?
No, I don't think that's right. The linking mechanism does not change your obligations under any of the licenses for Qt 5.12 (commercial, GPL, or LGPL).
If you use Qt under LGPL, remember that one of your obligations is to allow your customers to replace the Qt libraries. Dynamic linking provides one way to fulfill this obligation -- as long as you enable your customers to replace Qt's *.so files on your device, then the LGPL allows you to release your own software under whatever license you want.
Another way to fulfill that obligation is to make your own code open-source and allow your customers to build your code from source. This way, they'll be able to replace Qt even if you used static linking.
So if my Qt app is covered by my Small Business Commercial Licence for development, Yocto meta-qt5 is covered by MIT license, and I'm dynamically linking to qt5, do I even need a distribution license?
If you use Qt under the commercial license, then you would've agreed to Section "3.3. Distribution of Devices" where you're obliged to buy Distribution Licenses to use Qt on embedded Devices. The linking mechanism has no bearing on this obligation.
Questions specific to this thread
From my layman's understanding, I'd have to host the source code for my Qt application - this is fine. In my scenario, the Qt code only forms a small part of the running system so it wouln't be very useful to the communty
Important question: Which parts of your device will stop functioning if the Qt-based parts are taken out? How do the other non-Qt parts interact with your Qt-based parts?
Note: "Publishing source code" is not the same as "releasing source code under an open-source license". Just because someone can view the code doesn't mean they've received the freedom to use your code.
My device doesn't use Boot to Qt, it uses Yocto linux which has no distribution restrictions as far as I'm aware
Yes, Yocto gives you the freedom to distribute as you please.
running my Qt app on meta-qt5 layer which is covered by an MIT licence. Some sources say that it isn't part of Qt, so what are the restrictions/obligations for this?
Yes, the Yocto layer is a separate thing from Qt. Therefore, your obligations to meta-qt5 (if any) are separate from your obligations to Qt.
The MIT's terms are quite short and sweet: https://tldrlegal.com/license/mit-license
-
@loopyengineeringco well, the price is sadly normal. I was surprised myself, when I first encountered this!
As I'm not a lawyer, I do not know how much truth/legality is to the following mind game:
You could sell your linux device without your Qt application on it and provide your customer with a linux installer to easily install it him/herself.
-
@J-Hilk That's certainly interesting, but I imagine it would fall into the avoidance realm.
I understand the fee and don't have too much issue paying it, the product's market is fairly elastic so would just mean an increase in price.
But it's the initial purchase of the pack that makes me a little light headed. I have to find a 7k EUR investment just to start my experiment.
It would be a shame for the device to never see the light of day just because Qt can't accept royaltys on sale instead. -
Hi, and welcome!
(Disclaimer: I am not affiliated with the Qt Company; this post reflects my personal observations and understanding as a member of the open-source Qt community)
Qt is accessible to a diverse range of developers. At one end of the spectrum are the commercial/industrial powerhouses like LG which uses Qt in smart TVs or Mercedes-Benz which uses Qt for in-vehicle infotainment. On the other end of the spectrum are individual hobbyists who tinker with Qt at home in their spare time.
The licensing structure is well established for these 2 groups above: The commercial licenses are primarily targetted at the commercial/industrial powerhouses; the open source licenses are primarily targetted at the hobbyists (as well as organizations of all sizes that produce open-source software).
A brief history of mid-range offerings
The middle of the spectrum is less clear, however. The Qt Company tried different mid-range offerings in the past, but they didn't work out:
- Indie Mobile licensing, targetted at mobile app developers:
* https://www.qt.io/blog/2014/10/01/benefits-of-the-indie-mobile-licensing
* https://www.qt.io/blog/2015/07/06/indie-mobile-available-until-aug-31st - Qt for Start-Ups, targetted at start-up companies for desktop, mobile, and embedded development
* https://www.qt.io/blog/2016/03/08/qt-start-ups-awesome
* https://www.qt.io/blog/2016/05/10/qt-for-start-ups-get-it-cheap-while-you-still-can
One of the main challenges faced by the Qt Company -- and probably one reason why the previous mid-range offerings didn't survive -- is that the open-source Qt offerings are direct competitors to the commercial Qt offerings.
Large companies might find commercial licenses attractive, but many small-to-medium sized groups prefer the open-source licenses. We have a chicken-and-egg problem: If there are too few buyers, the Qt Company can't offer an attractive price. If the price is not attractive, there will be few buyers.
The Qt Company has a new offering now (Qt for Small Businesses https://www.qt.io/blog/available-now-qt-for-small-businesses), which I hope is more successful that its predecessors. However, as you've discovered, the embedded distribution pricing is more geared towards a small business that is planning to make embedded devices a main source of income, rather than a spare-time experiment.
Your options
It sounds like the 7k EUR fee is quite heavy for you, but it's not a complete show-stopper. I can see 2 main possibilities:
- Go all-in: Make this project a priority rather than a side experiment; take full advantage of the support + tools that come with the commercial license to polish up your device, reduce time-to-market, and market it hard to sell more units faster. OR,
- Use an open-source license for your experiment. Familiarize yourself with the rights and obligations offered by the LGPL (and GPL if you use certain modules) and sell your devices with open-source Qt.
Be aware that if you start with the open-source route, you can't transition the same code base to a commercial license at a later stage.
All the best with your project.
- Indie Mobile licensing, targetted at mobile app developers:
-
@JKSH said in Is distribution licensing cost really that huge for low volume embedded devices?:
LGPL
Thank you for such a detailed response, it sets out very clearly where the problem lies - I think I fall into the middle ground which isn't explicitly catered for by Qt Company. Which I totally understand.
I have looked into the open source licensing model before, but even after many questions, webinars & research I feel completely lost trying to grasp the possibilities/rights/obligations of LGPL/GPL.
I appreciate this is out of scope for this thread, but maybe you would be able to answer a few questions (maybe this will be helpfull to the community too)?
From my layman's understanding, I'd have to host the source code for my Qt application - this is fine. In my scenario, the Qt code only forms a small part of the running system so it wouln't be very useful to the communty - it's just a obligation fullfilment excercise, but fine.
My device doesn't use Boot to Qt, it uses Yocto linux which has no distribution restrictions as far as I'm aware, running my Qt app on meta-qt5 layer which is covered by an MIT licence. Some sources say that it isn't part of Qt, so what are the restrictions/obligations for this?
Where is the cut off for paying the the discribution license? When I compile my Qt app for Arm? Whether I link statically or dynamically it doesn't really matter, and I think dynamic linking would mean that I'm licence-free. Is this right?
So if my Qt app is covered by my Small Business Commercial Licence for development, Yocto meta-qt5 is covered by MIT license, and I'm dynamically linking to qt5, do I even need a distribution license?
-
You're welcome; I'm happy to share what I understand. For simplicity, I'll only discuss Qt 5.12 LTS with 3 license options (GPLv3, LGPLv3, and the commercial license).
Disclaimers:
- This is a simplified, illustrative, and incomplete overview. It aims to help readers to start to understand certain licenses, but readers must still delve deeper to fill in the gaps.
- There is no guarantee that lawyers, judges, the Qt Company, or the Free Software Foundation will agree with my post.
A brief overview of the GPL family
I have looked into the open source licensing model before, but even after many questions, webinars & research I feel completely lost trying to grasp the possibilities/rights/obligations of LGPL/GPL.
I believe that many people are used to thinking of licenses in terms of pricing and restrictions ("How much does this software cost? How many people are allowed to use this software simultaneously when I buy this tier?"). The GPL family can feel foreign because it is primarily concerned with the freedom to run, study, modify, and share code instead of pricing arrangements.
In the beginning, there was proprietary software. Users of proprietary software often have no right to even view the source code, much less modify the code (to apply their own bugfixes/improvements) or share the code with their peers. The GPL was created to guarantee these rights to users. When someone releases software under the GPL, they're basically saying, "I give you the freedom to study my software's source code and modify it to your heart's content. I give you the freedom to share my code with whomever you please. I give you the freedom to incorporate my software into your own software. In return, you agree to offer all the same freedoms to your users by releasing your software under the GPL too."
Many companies could not accept the GPL model, so the LGPL was created as a compromise. When someone releases software under the LGPL, they're basically saying, "I give you the freedoms offered by the GPL. However, when you incorporate my software into your software, you're not obliged to pass on the full set of freedoms to your users -- you just need to offer those freedoms on my part of the software; you're free to license your other parts as you please."
Applying this to general embedded projects that use Qt 5.12
Most of Qt 5.12 is triple-licensed. That means you can choose to use Qt 5.12 under the commercial license, or the LGPLv3 license, or the GPLv3 license.
If you use Qt under (L)GPL, you are must give your end-users the right to study and modify source code.
- If you use Qt under the LGPL, your end-users must be able to replace the Qt libraries with a version of their choice. Your device must continue to function after they perform the replacement (unless Qt itself broke compatibility with your original version). You must provide your end-users a copy of the Qt source code or make it clear to them that you will supply the Qt source code upon request.
- If you use Qt under the GPL, you must do everything you'd do under LGPL, PLUS you must also offer the same freedoms to all of your code that won't work without Qt. (In other words, you give your customers the freedom to modify and rebuild your code)
In addition, if you use Qt under (L)GPL, you must:
- Make it clear to your users that your device uses Qt.
- Provide a copy of the (L)GPL license to your users.
- Publish any changes that you've made to the Qt source code.
If you use Qt under the commercial license, you don't have to offer any of the above. Instead, you must:
- Pay the Qt Company the fees as specified in the license
- (For small businesses) Allow your finances to be audited
- Take care not to mix software you've developed under commercial Qt with software that you've developed under open source Qt
- Forbid your users from modifying and sharing Qt and your software
(Note: The lists in this section are not exhaustive)
How does static/dynamic linking fit into the picture?
Where is the cut off for paying the the discribution license? When I compile my Qt app for Arm? Whether I link statically or dynamically it doesn't really matter, and I think dynamic linking would mean that I'm licence-free. Is this right?
No, I don't think that's right. The linking mechanism does not change your obligations under any of the licenses for Qt 5.12 (commercial, GPL, or LGPL).
If you use Qt under LGPL, remember that one of your obligations is to allow your customers to replace the Qt libraries. Dynamic linking provides one way to fulfill this obligation -- as long as you enable your customers to replace Qt's *.so files on your device, then the LGPL allows you to release your own software under whatever license you want.
Another way to fulfill that obligation is to make your own code open-source and allow your customers to build your code from source. This way, they'll be able to replace Qt even if you used static linking.
So if my Qt app is covered by my Small Business Commercial Licence for development, Yocto meta-qt5 is covered by MIT license, and I'm dynamically linking to qt5, do I even need a distribution license?
If you use Qt under the commercial license, then you would've agreed to Section "3.3. Distribution of Devices" where you're obliged to buy Distribution Licenses to use Qt on embedded Devices. The linking mechanism has no bearing on this obligation.
Questions specific to this thread
From my layman's understanding, I'd have to host the source code for my Qt application - this is fine. In my scenario, the Qt code only forms a small part of the running system so it wouln't be very useful to the communty
Important question: Which parts of your device will stop functioning if the Qt-based parts are taken out? How do the other non-Qt parts interact with your Qt-based parts?
Note: "Publishing source code" is not the same as "releasing source code under an open-source license". Just because someone can view the code doesn't mean they've received the freedom to use your code.
My device doesn't use Boot to Qt, it uses Yocto linux which has no distribution restrictions as far as I'm aware
Yes, Yocto gives you the freedom to distribute as you please.
running my Qt app on meta-qt5 layer which is covered by an MIT licence. Some sources say that it isn't part of Qt, so what are the restrictions/obligations for this?
Yes, the Yocto layer is a separate thing from Qt. Therefore, your obligations to meta-qt5 (if any) are separate from your obligations to Qt.
The MIT's terms are quite short and sweet: https://tldrlegal.com/license/mit-license
-
@JKSH Thank you again for your time to write such a detailed answer!
LGPL seems like a very viable route for me. Also as you explain, using the open source Qt would mean I'm not obliged to purchase the distribution licenses. This point is the most helpful to me.
Interestingly during my research I found that Electrolux are using Qt for their GUIs on an open source license. While they probably have a very strong compliance department, it's a positive sign in that if it's good enough for them, I'm sure I can make it work. (https://www.youtube.com/watch?v=bwTlCBbB3RY)
It's funny that I'm fairly happy to be a paying customer (definitely for the dev/design tools) but the bulk-only pricing is turning me into a non fee-paying customer.
To answer your point:
- Important question: Which parts of your device will stop functioning if the Qt-based parts are taken out? How do the other non-Qt parts interact with your Qt-based parts?
The particular device in questions is a HMI display, so if the QT component is taken out it becomes mostly useless. Qt/linux communicates to an MCU via UART to fetch data to display and set various settings to eeprom. It doesn't have any control over the hardware it's attached to.
I do have other projects which do control hardware, however.
Would this have any implications? -
You're most welcome :)
@loopyengineeringco said in Is distribution licensing cost really that huge for low volume embedded devices?:
LGPL seems like a very viable route for me. Also as you explain, using the open source Qt would mean I'm not obliged to purchase the distribution licenses. This point is the most helpful to me.
...
It's funny that I'm fairly happy to be a paying customer (definitely for the dev/design tools) but the bulk-only pricing is turning me into a non fee-paying customer.
Coming up with a good business model that benefits both the buyer and seller is hard work. The Qt Company is continuously innovating.
Anyway, if you receive benefits from LGPL'ed software (in terms of social/legal freedoms and reduced monetary burdens), please have a think and see what kinds of freedoms you can pass on to your customers/users too. You can also look for opportunities to "pay back" the Qt Company in non-financial ways (for example, submitting bug reports, submitting patches, or helping to answer questions on this forum). This will help keep the LGPL model sustainable.
To answer your point:
- Important question: Which parts of your device will stop functioning if the Qt-based parts are taken out? How do the other non-Qt parts interact with your Qt-based parts?
The particular device in questions is a HMI display, so if the QT component is taken out it becomes mostly useless. Qt/linux communicates to an MCU via UART to fetch data to display and set various settings to eeprom. It doesn't have any control over the hardware it's attached to.
I do have other projects which do control hardware, however.
Would this have any implications?There are ongoing debates on whether a separate piece of software is truly separate if it cannot function without the (L)GPL'ed bit.