LeanQt VS NAF

> Then do you (developers on HN) stay away from CLAs?

Depends on the CLA, but generally I do stay away. E.g. I never checked in anything to the official Qt repository because I don't agree the the CLA by QTC. Instead I finally made my own fork and call it LeanQt and LeanCreator (see https://github.com/rochus-keller/leanqt/ and https://github.com/rochus-keller/leancreator/).

The "weird licence which is basically a modified version of the MIT licence but with a clause that prevents competitive usage" is likely not even recognized as a true "open source" license.

> would it be possible to relicense a fork of Polaris to MIT (removing the Shopify clause?)

Likely not, because only the IP owner can determine who can do what with their IP under what license. If you use the software of an IP owner under a specific licence, you usually don't have the rights to re-license their work, even if you modified it.

My response to this question was https://github.com/rochus-keller/LeanQt, but I'm not using QML nor xmlpatterns.

I made myself independent of the adventures in Qt Land by switching to https://github.com/rochus-keller/LeanQt.

https://github.com/rochus-keller/LeanQt

A minimum and easy to build fork of QT

If you (like me) don't need all that stuff and are not up to the latest craze, have a look at LeanQt (https://github.com/rochus-keller/LeanQt).

Right. In the Gui module you have everything you need for this: platform independent windows and events, 2D bitmap and vector graphics, fonts and even rich text handling. Unfortunately there are some dependencies in Qt Gui to Qt Widgets, but if you use e.g. https://github.com/rochus-keller/leanqt/ instead of original Qt these are resolved. So with this you can implement your own widget toolkit on top of the Gui module if you want, and still benefit from the very powerful platform independent foundations of Qt.

> Qt for MCU [..] seems like a big advantage over Qt LGPL-3.0. I have my doubts. MCUs powerful enough to run Qt GUIs smoothly are more expensive than, say, an i.MX6ULL with a Cortex-A7 application processor and Linux. It’s a lot easier to find developers for an embedded Linux system ...

This is a very convincing argument. A Linux embedded system is also more flexible and the degree of code reusability is usually higher.

> Shall we use Qt LGPL-3.0 or Qt Commercial?

LeanQt (https://github.com/rochus-keller/leanqt/) is still available under LGPL v2.1. I will not switch to Qt 6 with my projects.

> no scripting support ... No SQL

It's mostly about concentration of responsibilities, or as they say on Unix: "do one thing and do it well". Scripting support can easily be delegated to other projects (LeanQt inherits meta and introspection facilities of Qt which make dynamic bindings easy to accomplish, see e.g. this one for Lua: https://github.com/rochus-keller/NAF/tree/master/Script2); the same applies to database integration and other topics.

That's actually not so difficult; Qt has good provisions for this (e.g. the meta type/object system with introspection, properties and the like which can be examined and used at runtime); the Qt company themselves offer a Python and JavaScript binding. I'm often mapping Qt objects as Lua user data which can be easily abstracted away even in C++98 (see e.g. https://github.com/rochus-keller/NAF/tree/master/Script2).