Hello team,
I want to know about the licensing for developing QT Apps on Toradex boards.
Like I am designing a system that will be using QT Widget in them , Then what am I suppose to do if I am using opensource QT Varient, Can i sell the Boards with QT Running over it in commercial products !
1 Like
I have worked for customers that used OpenSource Qt 4.8 for commercial products. Honestly I think they had lawyers that were kicked out of Hell because Satan was afraid of them. Qtc was badgering the manager to buy license and provide a never ending revenue stream. One phone call from the lawyers to Qtc (or whatever name they had then) and the manager was contacted with
We find you pious and Holy, go with the grace of God.
There have been no end of battles and questions about licensing on the interest mailing list.
https://lists.qt-project.org/mailman/listinfo/interest
Search the archives.
https://lists.qt-project.org/pipermail/interest/
Every response from Qtc is always “talk to your sales rep.” Every sales rep says you need to buy a license. (I suspect they are paid on commission.)
There is no longer a perpetual license. There no longer is an OpenSource LTS. Everyone tells me it is “annual license renewals” and “subscriptions.” If you stop paying you have to pull your product from market.
You can get a more accurate answer from someone at Toradex about the new license arrangements, but as far as Qtc is concerned, their view is that everyone needs to buy a license. What does and does not qualify for “OpenSource use” seems to change by the minute/message on the mailing list. Pull down a few years of the text files zipped and grep them for license conversations.
A client of mine reached out just this past week to inform me they will no longer be using Qt going forward. They actually have stuff on the market using the older Qt perpetual license.
If you are using Widgets, see if you can be of assistance or fund the Toradex ARM port of CopperSpice. This is a fork of Qt 4.8 prior to the New World Order taking possession. They ripped out QML and changed a bunch of stuff. Unlike Qt, that is a true OpenSource project. There are no licensing fees but you can purchase support contracts. I do not know what the current state of ARM support is. I know a bunch of Apple users seem to have fixed it for the Apple ARM processors but I haven’t seen anything come into the code base or any official announcement.
You can find unofficial Debian packages here.
My pull request hasn’t gone through yet but I needed packages for some OpenSource projects I’m working on.
Before this new licensing chatter from Qtc, I had one client in the past 5 years that purchased a license. After much negotiation they paid north of $600K for five developer seats and no royalties. I gotta believe that for less than half of that they could have hired someone, bought them hardware, and had them complete the port of CopperSpice to the target.
If you are bored today, pull down the source, spin up an ARM development docker/VM, and see how far you get building it using buster on your target. Given it already builds for Linux, several Windows platforms, and some MAC stuff, I can’t believe it is that far away from actually working.
Yes, there are many commercial products on the market using OpenSource Qt. Most are holding their breath hoping the New World Order doesn’t come knocking. If they do come knocking, do you have the lawyers it takes to scare them back into a dark little hole?
1 Like
Here’s some more “light” reading you may wish to consider.
CopperSpice looks interesting. Has anyone been able to compile it for WEC2013/ARM? I don’t really want to write QML for my interfaces, nor pay $600k licensing fee. 
I tried compiling Qt 5.6.3 for WEC2013, and although it cross-compiles, I can’t get it to actually run on the Toradex module.
I have not tried to compile CopperSpice for ARM. If you have the hardware and a spare development VM, spend an afternoon.
There are many choices linked in the blog post I provided.
If you were all the way out developing with Qt widgets and only asked about licensing after the fact, taking it upon yourself to build CopperSpice for ARM is a worthwhile use of your time. It may take you a few days posting questions on the CopperSpice forum, but you should know in a few days if you will succeed. As to the current state of the ARM port, that would be the place to ask.
You really should read the blog post no matter what so you don’t go down the legacy path of One Ring to Rule Them All. People who have only written software in the x86 world have the fatal architectural mindset of stuffing everything into a single executable. With event driven application frameworks that ends up meaning everything must happen in the main event loop running in the primary thread. You can’t thread off meaningful things.
You can still use such an application framework, but you must bust up your design so you have independent processes performing each task.
I don’t know what they charge for their drag and drop UI editor, but LVGL itself is OpenSource UI only. Almost everyone is going with UI only libraries these days for new product development. LVGL has some significant backers. I have yet to use it.
If you want something that will compile just fine for Toradex ARM (because I did it last year some time) Nuklear is one to consider. It is a single header file UI library written using C89. It takes a bit more work to make sexy UI, but a clean looking functional UI isn’t really difficult. Just start with one of the demo applications pictured in the gallery.
Nuklear itself was archived on Github Dec 2, 2019. It also has 1.1K forks so you can probably find fixes to any issues if you follow the tags to the forks.
NanoGUI is another choice for immediate mode light weight GUI. It wouldn’t build to run under Wayland only a year or so ago, but there has been work in that respect, I just haven’t followed. It works awesome in a buster Docker container running X11 and the Wayland Vivante thing has enough X11 client/server built in. The big downside with all things Wayland is that you cannot control screen position unless you use the entire screen.
WaylandGUI is a fork I created of NanoGUI trying to get it to run directly under Wayland. Some others on here are using it. I’m not maintaining it as I don’t need it for a project currently. The vast majority of what I was doing was ripping stuff out because you cannot build under Wayland if you have even one X11 header. I believe I got it to work, but that was several projects ago.
Elements can be used to make some very nice looking UIs. Again, when I touched it just over a year ago it wouldn’t build or run native
There is always wxWidgets if you need a kitchen sink GUI. It claims active ARM support and I know a competitor of Toradex has some kind of webinar on how to develop for their ARM processors using it. There are quite a few desktop applications using wxWidgets. CodeBlocks IDE and Audacity would be two you’ve probably heard of.
You could try going old school with OpenZinc.
Not my blog, but this guy put together a good run-down of most solutions. Be careful trusting the “dead” list. OpenZinc has died a couple of times. It periodically sputters back to life.
For some reason the FOX Toolkit isn’t on the above list. Admittedly it has something of a Windows 95 look and feel. It is actively maintained and does have a developer mailing list as well as a list archive. One of the “demo” applications for it is the Adie editor written with the toolkit. Yes, the screen shot looks incredibly cheesy but the editor does work fairly well. You can ask if anyone has cross compiled to ARM if you try it and like it. The intriguing part of the library is the massive list of old platforms it still builds and runs on.
The list of platforms is growing! Currently, we have FOX running on a large number of operating systems, ranging from Linux, FreeBSD, SGI IRIX, HP-UX, IBM AIX, SUN Solaris, DEC/Compaq Tru64 UNIX, to MS-Window operating systems like Windows 9x, Windows NT, Windows ME and Windows 2000. Since most of the FOX implementation is completely oblivious to the underlying platform (in many cases it is not even including header files), applications work virtually identically on all these platforms.
I only kicked the tires on FOX. I do not remember if I was able to compile for my Toradex target or not. I know the ultimate end client wanted “sexy” for the UI and ruled it out after seeing the pixelated screen shots on the Web site.
Suggestion for Toradex
Can you parse this endless stream of consciousness that is my reply into some form of official documentation, perhaps a wiki. That way when someone builds one of the things for your ARM they can update the success status and build process.
This question comes up a lot.
I’m developing for products that need at least a 5-7 year stable lifetime. I cannot rely on some flash-in-the-pan side project for interface development. We’ve been looking at Crank, Qt Embedded, Embedded Wizard, etc. All of these are expensive for low volume instruments, and require some new language and “glue logic” to talk to C/C++ which is the core of my firmware. I’d rather not have to learn a new language, be forced into some spaghetti graphic designer for multiple screens, and write a bunch of glue logic. I also need something that is touchscreen friendly and looks somewhat modern, or at least clean with decent font support. Animations are secondary and only icing on top.
1 Like
Well, I work on medical devices. Patient monitors, infusion pumps, and diagnostic equipment mostly. Been in IT over 30 years and doing this the past 10. The “stable lifetime” thing is a Red Herring. In the medical device world we are required to lock down our dev tools and environments. There is a formal FDA document we must file with each device that lists each tool/library and specific version. We also have to perform a full static source code analysis.
Once we settle on a tool set, we park it on one or more servers we maintain so it can never be lost or updated. You cannot use a new version of anything to fix something found in clinical trials or the field. Updating the dev VM or any single library would require another 510K filing for at least a “minor change” which still requires external QA testing and review. You may get around the clinical trials, but that is all you get around.
Nothing commercial is going to be cheap. Upper management has a lifestyle it wishes to become accustomed to and you have to fund it. The days of a $350 commercial GUI library ended with MS DOS.
I can tell you for a fact that there is a medical device entering clinical trials now that used Elements for its UI library and it has a touch screen. That’s all I can tell you about that device until it hits the market.
With every medical device, one examines the UI requirements then chooses the lowest cost highest quality library they can relative to product volume. If you are shipping 7 million units per year you go with altia medical. Sometimes you go with the medically certified version of QNX either using its UI or Altia.
Low volume means OpenSource. Since it will not be medically certified you need it to also have a limited amount of code that you included in your own repository. Once in your repository you must modify it to the project coding standard and perform static source analysis on it. That’s before you use it in your project. That’s why you see a thousand forks of Nuklear. It’s also why you see nearly 200 forks of Elements.
I tried to assist. I will assist no more.
1 Like
I do appreciate the wisdom of your experience and your suggestions. I will follow-through at looking at some of these options. My company invested many man hours writing their own basic screen layout language, somewhat similar to ML, for text-based touchscreens and it renders using Cairo and other open source libraries. My quandary is whether to continue development of this to support more advanced graphical features or move on to something else.
I am aware nothing commercial will be cheap, but I have to fight the sticker shock attitude from management that doesn’t understand the many man hours they’ve invested over time in a “not-invented-here” approach to achieve the same. I fear some of the open source projects you mention are more of the same.
I read some of your blogging and I agree to a point. What I don’t necessarily understand is the wholesale aversion to main event loops for user interfaces. A user can’t typically do more than one action to an input device at a time for a single area of a screen (we aren’t octopi with compound eyes), so a single event loop for an interface does not seem unreasonable to me. What we all are taught is to try to separate the computational aspects of your apps from the user interface – this can be done with threading or, yes, multiple “apps” that use a shared memory space (an approach used on one of my company’s recent laboratory instruments).
If someone is writing a Qt application and it is sprinkled throughout with processEvents(), then I would argue it was poorly designed from the start. But even then it makes sense sometimes to make a user wait if something takes a bit to load and display – the user can’t continue working on something that is not even visible yet! Qt has some flexibility in the scheduling/order of the signal/slot execution you can use to your advantage when needed as well.
Take some time and re-read with fresh eyes. You missed the point of the blog post. It is a wholesale aversion to an application framework mandating a primary event loop in the primary thread.
Ordinarily I don’t care about the UI locking up while busy. What I do care about is the blood pressure cuff not being able to alarm because the UI is locked up. Someone dies because the nurses station can’t be notified. It could be an occlusion for an infusion pump, or whatever. Due to the pathetic design of all rendering being forced to the main event loop, you can’t create a safe product. Even the network stuff is there so you can’t even reach out to the remote nurses station to alarm.
If you are using a real production quality database and the QTableWidget in your application, you are going to scatter processEvents() everywhere and it has nothing to do with your application design. It’s the short sighted design baked into Qt.
In Qt, rowId has to be unique. It supports PostgreSQL. The rowId is only unique within a segment. For PostgreSQL to support databases with tables many TB in size, once a table exceeds 64-bit rowId, a new segment is created. Something like 32,767 segments can be created, each having a full 64-bit rowId filled from 0-max before you have to use the next grouping layer . . . I forget the name. I think right now you can only have 0-255 of those but don’t quote me.
Unless you gut and hack and write mostly your own, the QSqlTableModel has to run in the primary event loop. When you issue a query against a database of that size, the wheels come off the cart. Some of the older data may be in cold storage (spun down drives or a robotic tape library). You could wait twenty minutes for it to return.
If memory serves, they also used an int instead of an unsigned int for the scrollbar and table range. What happens when your cursor returns 25 segments of full 64-bit values?
Every medical device that issues a remote query for patient data runs this risk. Either it is too large a chunk to consume or they have to wait their turn for the robot. Too large, all crash. Too long, UI lock up entire time without processEvent() calls.
When it comes to medical device projects, I know I have to maintain 100% of the code. I have no fear once I have converted the OpenSource code to the Barr standard and cleaned up static analysis. That’s not being cocky or anything. Simply gave up being able to abdicate responsibility to third party long ago.
Take a good look at just how large the open bug database is for Qt right now. It was 16K deep last I looked. No way I’m using that in an FDA regulated project. I think some of the OpenSource projects I pointed you to don’t have 16K lines in their code base.
Those are all great points. I’m thinking back on all the stuff I’ve written with Qt (and other similar frameworks) for applications where I have had to deal with what you describe. So you are telling me that there are user interface framework designs out there that do multiple interface event loops for different areas of a screen?
Regarding the interface stalls, I’ve had to deal with that in many apps over my career. It’s just part of the job. You have to learn to break the big things into smaller pieces or risk spinning cursors of death.
For example, I had to develop an in-cockpit display for a company reading utility meters from the air. I would load up a list of thousands of meters (using QMap) with the lat/long of each and display those over a realtime map following the ground track of the airplane. I did run into stall problems if the user wanted to display a very wide view map of the entire service region with thousands of meters plotted. But, if the user zoomed in to a more reasonable map area during real flight, the response of the app was quite snappy with excellent details in the maps (down to street level with structure outlines). While it would be great if the stall wasn’t an issue with the wide area view, the problem is showing thousands of meter locations on a small screen map of a wide area was of no real use anyway. It would be just be a solid mass of points over a very high level map with maybe only the major routes shown and labeled. You cannot see any detail at that scale.
I would argue the same for some of the things you describe. Anyone who thinks you can load a million rows into a widget table and have it be of any real use to a customer is a fool. There is an art to user interface design. I have had to deal with many engineers who have no concept of how to build an interface that is both useful and can easily be digested by the customer. Simply throwing up the largest amount of data you can usually results in a terrible interface experience.
Another example that is currently in use is a heat treatment app in my present company. I wrote the managing app in Qt. There is a problem when the user wants to see data recorded every 30 seconds in a plot over a 6 week heat treatment schedule. Again, doing this as a user is dubious because unless you are looking for long-term trends, you can’t see any detail in so much data crammed into such a small screen space. But the interface will happily do it and it will stall everything while it does so. That means you cannot close the vacuum valve using the button on screen while the interface is stalled drawing your crazy plot. Yes, I’d love to fix that but I can’t throw away the 95% usefulness of the app because of this one problem. It’s been in use now for years and a lot of stuff has successfully shipped using it.
Also, there is the issue of manpower. With the meter reading app I describe above, I was one developer in a startup with 3-6 months available to “get something done we can use”. I didn’t have time to reinvent the entire wheel – I have to be able to leverage a framework to be productive in that situation. I would say Qt helped me develop something that worked well enough to get the job done in the time I was allotted. If the company reading meters had grown to a huge enterprise (the company ultimately failed because of marketing, not technical issues), then perhaps the resources would have been there to take a different approach and work on getting rid of all those possible stall points in the interface – even the crazy wide-area view of hundreds of thousands of meter locations.
I see your point with medical applications. Unfortunately a life is on the line and you don’t have the luxury of saying “this is the best I can do with the tools at my disposal in the time you have allotted.” Ultimately whatever can solve the issue for medical apps can make life safer for all of us for other applications.
Is the only answer developing multiple applications to service different interface categories on a common screen? Or did I miss your point again? Here it seems you are relying on the operating system to slice up the responsiveness of the overall interface for you. I know have run into problems in the past where even the operating system’s screen rendering engine is single-threaded. MacOS, for example, will stall the update of an app in the background if its interface is not visible on the screen! I’ve used a utility that stacks Windows 10/11 applications in a tab layout and the execution of the background tabs will stall!
So, again, can you show me an application framework for user interface design that doesn’t suffer from these kinds of issues that doesn’t cost a small fortune and gives me comparable productivity for 95% of the things I need to do as a single developer? As I single developer I simply cannot reinvent the wheel from first principles for every task. I hear a lot about QNX but I confess I’ve not researched it enough to even have an opinion.
Many thanks for you insights.