4 ms·

It's still free under lgpl. Their open source version anyway. [1] Just that the Qt company lately has been trying everything to scare / annoy people into getti

It's still free under lgpl. Their open source version anyway. [1] Just that the Qt company lately has been trying everything to scare / annoy people into getting licenses, sign up for their online accounts etc... So they're just not advertising their open source offerings as much. 1. https://www.qt.io/download-open-source https://www.qt.io/download-open-source

nextaccountic 5y ago
Why if I don't allow any audit, what they could do? They can't revoke the LGPL license, and there's nothing in the license that mandates such audits..
- saidinesh5 5y ago
  I honestly don't know. I mean i routinely see so many GPL violations too and all i had to do was grep the binaries/update packages for strings like GPL. All i can tell you is most of the small-medium sized companies i worked for over the last few years are still using the very old and outdated Qt 5.6 just to avoid the newer LGPLv3 license. In fact i haven't heard of anyone who purchased a Qt Commercial license to date.
  - joezydeco 5y ago
    I'm a licensed commercial Qt developer, been so for about a decade now. My current org is still on 5.15 (the latest LTS release) and that's as far as we're going. I'm relieved they at least offered to go beyond 4.8 (the LGPL3 switchover) but that's mostly because other projects were already doing it. We're never going to Qt6, the newer licensing terms are just too much for us. Calling v5 old and outdated is subjective - we develop 2D interfaces on Linux framebuffer and that's good enough for the task. It's a bit sad that Qt is focused on 3D stacks and particle effects and acceleration and - mein gott in himmel - I just got an email about in-app advertising coming to Qt6. While core features and deficiencies in the system have gone unaddressed for years, sometimes nearly a decade. Sadly the next generation of our products will be going to React or Electron. So now we need to beef up our hardware and burn millions of unnecessary watts over the decades because we will need Node or some other backend server running on our little devices. They've won, and I'm sad about it.
    - ldiracdelta 5y ago
      I've used qt professionally for years and have been slowly coming to the same position, but I'm wondering about going the other direction with performance and using lvgl.io for GUI only and all the backend server communication and business logic in rust. Lvgl.io is beautiful and it runs all the way down to esp32-connected devices.
      - saidinesh5 5y ago
        With QML/QtQuick all/most of the ui is rendered on the GPU though. That leaves the CPU free to perform other tasks. Even at 1080p 60 fps your CPU usage sits under 10% on cheap iMX6 devices. With lvgl it looks like it doesn't utilize that GPU much, so as you move to higher resolutions, your performance and fps drops hard. If you're doing video rendering etc... That will be a pain. (Take a look at CPU usage on their YouTube videos)
        ldiracdelta 5y ago
        Yeah, I think you would use other native technology for videos, but for simple UIs? If it can work on an ESP-32, it can work on x86 big-iron. ( I don't have a dog in this fight, yet, so tell me how I'm wrong.)
        saidinesh5 5y ago
        Oh it really depends on your use case and the hardware you use for embedded devices. If all you need are some buttons and some kind of static lists, lvgl should be fine too. But for anything where you want things like smooth scrolling/higher resolutions you probably want to use the GPU. For eg. A badly implemented "speedometer widget" was making our whole embedded GUI stutter at 15-20 fps and 100% cpu usage (which caused other problems like overheating, timing problems etc...). 5 lines of change to make the GPU do most of the work and we were back to smooth 60fps and low cpu usage. At my last job, the requirements were like: you might as well directly target embedded linux socs instead of microcontrollers like ESP-32, because the price difference between them is not that much for the number of these devices we wish to sell.
  - nextaccountic 5y ago
    ... what's the trouble with LGPLv3? Is Qt under LGPL 2.1? Were the changes so drastic?
    - saidinesh5 5y ago
      The main problem with LGPLv3 is the anti-tivoization clause. That means you should basically provide the end user a way to replace the Qt libraries with their own. On embedded systems this can mean headaches for companies releasing commercial products. More details: https://embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/ https://embeddeduse.com/2016/04/10/using-qt-5-6-and-later-un... Qt from 4.8(?) To 5.6 offered an LGPL2 license too but after that it's mostly LGPLv3 i think.
- IshKebab 5y ago
  I don't see why an audit would make any difference. If you're developing internal software you are free to use the LGPL version without revealing any code publicly. And if you're developing external software there's no real way you can hide the fact that you're using Qt. They wouldn't need to audit you.

nextaccountic 5y ago

Why if I don't allow any audit, what they could do? They can't revoke the LGPL license, and there's nothing in the license that mandates such audits..

saidinesh5 5y ago
I honestly don't know. I mean i routinely see so many GPL violations too and all i had to do was grep the binaries/update packages for strings like GPL. All i can tell you is most of the small-medium sized companies i worked for over the last few years are still using the very old and outdated Qt 5.6 just to avoid the newer LGPLv3 license. In fact i haven't heard of anyone who purchased a Qt Commercial license to date.
- joezydeco 5y ago
  I'm a licensed commercial Qt developer, been so for about a decade now. My current org is still on 5.15 (the latest LTS release) and that's as far as we're going. I'm relieved they at least offered to go beyond 4.8 (the LGPL3 switchover) but that's mostly because other projects were already doing it. We're never going to Qt6, the newer licensing terms are just too much for us. Calling v5 old and outdated is subjective - we develop 2D interfaces on Linux framebuffer and that's good enough for the task. It's a bit sad that Qt is focused on 3D stacks and particle effects and acceleration and - mein gott in himmel - I just got an email about in-app advertising coming to Qt6. While core features and deficiencies in the system have gone unaddressed for years, sometimes nearly a decade. Sadly the next generation of our products will be going to React or Electron. So now we need to beef up our hardware and burn millions of unnecessary watts over the decades because we will need Node or some other backend server running on our little devices. They've won, and I'm sad about it.
  - ldiracdelta 5y ago
    I've used qt professionally for years and have been slowly coming to the same position, but I'm wondering about going the other direction with performance and using lvgl.io for GUI only and all the backend server communication and business logic in rust. Lvgl.io is beautiful and it runs all the way down to esp32-connected devices.
    - saidinesh5 5y ago
      With QML/QtQuick all/most of the ui is rendered on the GPU though. That leaves the CPU free to perform other tasks. Even at 1080p 60 fps your CPU usage sits under 10% on cheap iMX6 devices. With lvgl it looks like it doesn't utilize that GPU much, so as you move to higher resolutions, your performance and fps drops hard. If you're doing video rendering etc... That will be a pain. (Take a look at CPU usage on their YouTube videos)
      - ldiracdelta 5y ago
        Yeah, I think you would use other native technology for videos, but for simple UIs? If it can work on an ESP-32, it can work on x86 big-iron. ( I don't have a dog in this fight, yet, so tell me how I'm wrong.)
        saidinesh5 5y ago
        Oh it really depends on your use case and the hardware you use for embedded devices. If all you need are some buttons and some kind of static lists, lvgl should be fine too. But for anything where you want things like smooth scrolling/higher resolutions you probably want to use the GPU. For eg. A badly implemented "speedometer widget" was making our whole embedded GUI stutter at 15-20 fps and 100% cpu usage (which caused other problems like overheating, timing problems etc...). 5 lines of change to make the GPU do most of the work and we were back to smooth 60fps and low cpu usage. At my last job, the requirements were like: you might as well directly target embedded linux socs instead of microcontrollers like ESP-32, because the price difference between them is not that much for the number of these devices we wish to sell.
- nextaccountic 5y ago
  ... what's the trouble with LGPLv3? Is Qt under LGPL 2.1? Were the changes so drastic?
  - saidinesh5 5y ago
    The main problem with LGPLv3 is the anti-tivoization clause. That means you should basically provide the end user a way to replace the Qt libraries with their own. On embedded systems this can mean headaches for companies releasing commercial products. More details: https://embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/ https://embeddeduse.com/2016/04/10/using-qt-5-6-and-later-un... Qt from 4.8(?) To 5.6 offered an LGPL2 license too but after that it's mostly LGPLv3 i think.
IshKebab 5y ago
I don't see why an audit would make any difference. If you're developing internal software you are free to use the LGPL version without revealing any code publicly. And if you're developing external software there's no real way you can hide the fact that you're using Qt. They wouldn't need to audit you.