Qt Offering Changes 2020(qt.io)
qt.io
Qt Offering Changes 2020
https://www.qt.io/blog/qt-offering-changes-2020
132 comments
This marks the of the end of a cooperative relationship and the beginning of a confrontational relationship.
Imagine getting a phone call like, "Can we send our license specialist to your premises and conduct an audit of your code?".
Leveraging Qt code just went from an asset to a liability.
Imagine getting a phone call like, "Can we send our license specialist to your premises and conduct an audit of your code?".
Leveraging Qt code just went from an asset to a liability.
Imagine getting a phone call like, "Can we send our license specialist to your premises and conduct an audit of your code?
I really wouldn't expect that from an organization from Qt, however I /would/ expect a call like:
"Hey, congratulations on your launch! We noticed someone from your org downloaded source from us about 18 months ago. Mind if we discuss your licensing plans?"
I really wouldn't expect that from an organization from Qt, however I /would/ expect a call like:
"Hey, congratulations on your launch! We noticed someone from your org downloaded source from us about 18 months ago. Mind if we discuss your licensing plans?"
>Leveraging Qt code just went from an asset to a liability.
So your company was previously violating the license and hoping nothing would happen? I certainly hope you don't randomly download code off the net just to do that.
So your company was previously violating the license and hoping nothing would happen? I certainly hope you don't randomly download code off the net just to do that.
FWIW if you bothered to check their website's language after Nokia (i think), Qt already had a confrontational relationship. It is just that they were slowly building it up over time.
And really, ever since the Trolltech days, Qt was dragged into open source kicking and screaming.
And really, ever since the Trolltech days, Qt was dragged into open source kicking and screaming.
In the Trolltech days, Open Source Qt was GPL-only. And up until Qt 4, the Windows port was Commercial-only.
Nokia introduced LGPL and open governance, simply because they were not interested in Qt as a commercial product, and The Qt Company is now trying to build a business around this. With huge companies like Tesla building their product around the free version of Qt without complying with the open source licenses, it is not that hard to see why they would look for ways to find out who their actual users are.
Nokia introduced LGPL and open governance, simply because they were not interested in Qt as a commercial product, and The Qt Company is now trying to build a business around this. With huge companies like Tesla building their product around the free version of Qt without complying with the open source licenses, it is not that hard to see why they would look for ways to find out who their actual users are.
Without more argumentation, this sounds like hysterics so common in the social media. Always jumping to extreme conclusions.
A lot of noise for no reasons.
You can not enforce login in for GPL / LGPL software distribution.
Meaning this is just probably that the "click/download" link for the binary official SDK on the official website will require registration, nothing else.
If it's really the case, they should be clearer in their explanations.
You can not enforce login in for GPL / LGPL software distribution.
Meaning this is just probably that the "click/download" link for the binary official SDK on the official website will require registration, nothing else.
If it's really the case, they should be clearer in their explanations.
They can enforce it for downloads from their site. By adding some non-free component into that process they can make it hard for others to ship those packages.
However as long as they use (L)GPL and don't play trademark games, they can't stop others from providing builds.
For such builds there is a question how trustworthy they are (afaik there are no reproducible builds for Qt) and how hard maintaining such builds is.
However as long as they use (L)GPL and don't play trademark games, they can't stop others from providing builds.
For such builds there is a question how trustworthy they are (afaik there are no reproducible builds for Qt) and how hard maintaining such builds is.
> For such builds there is a question how trustworthy they are (afaik there are no reproducible builds for Qt)
To their defense, very few organizations have reproducible build systems and when they have, it's not compatible with the package manager of the Linux distros anyway
To their defense, very few organizations have reproducible build systems and when they have, it's not compatible with the package manager of the Linux distros anyway
Right, but Qt builds one can probably trust. Some random account on GitHub less.
> Installation of Qt binaries will require a Qt Account
Uh, what? I use programs like VLC and QbitTorrent which are built on Qt:
https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...
does that mean these require Qt registration by the end user?
Uh, what? I use programs like VLC and QbitTorrent which are built on Qt:
https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...
does that mean these require Qt registration by the end user?
No, it means that if you want to bundle Qt binaries in your application, you as a developer, will need to be registered.
It doesn't say specifically
-dev binaries, it says 'installation of qt binaries' which I need to install any qt based software unless i want to build the libraries from source. If they mean bundling qt binaries in your app they should say that. This makes it seem like everyone needs to register to install anything that relies on having a qt binary installed on your system.
If I install qt through a package manager, do I need to be registered or would the package maintainer need to be registered?
If I install qt through a package manager, do I need to be registered or would the package maintainer need to be registered?
If you're installing through a package manager, you're probably installing something built from source rather than downloaded as a binary from upstream.
> If you're installing through a package manager, you're probably installing something built from source rather than downloaded as a binary from upstream.
I didn't get that impression from linked Qt blog post. I parsed the blog post to mean any/all binaries built. Eg if you build your own binaries from the open source license, you can't distribute them without a commercial or distribution license. Likewise, you can't download Qt binaries without a Qt account. It effectively locks out anyone who's not a developer and doesn't want a Qt account but does want to install some pre-built open source software.
I didn't get that impression from linked Qt blog post. I parsed the blog post to mean any/all binaries built. Eg if you build your own binaries from the open source license, you can't distribute them without a commercial or distribution license. Likewise, you can't download Qt binaries without a Qt account. It effectively locks out anyone who's not a developer and doesn't want a Qt account but does want to install some pre-built open source software.
> I didn't get that impression from linked Qt blog post. I parsed the blog post to mean any/all binaries built. Eg if you build your own binaries from the open source license, you can't distribute them without a commercial or distribution license.
They can't add such limitations without modifying the open source license, which they aren't doing.
They can't add such limitations without modifying the open source license, which they aren't doing.
It's LGPL'd. They can't add that restriction.
> The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, <...access to source code provisions...>
> The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, <...access to source code provisions...>
> Eg if you build your own binaries from the open source license, you can't distribute them without a commercial or distribution license.
Given it is a known open-source license, (L)GPL, this restriction is obviously impossible.
Given it is a known open-source license, (L)GPL, this restriction is obviously impossible.
It sounds like dynamically linking is ok, but statically linking against Qt is not.
Fair point on that. Still, the rest is somewhat unclear.
We'll have to see what license they apply to the binaries. As the copyright holder, they wouldn't have to use (L)GPL. If the binaries are redistributable, then maybe someone will mirror them. Otherwise, people can build them from source, as many Linux distributions already do. If the source license were changed to prevent that, then I think we'd see a hostile fork pretty quickly from the last free and open source version.
I don't think it says even that.
It says if you want to install Qt binaries from Qt website. You can still distribute the binaries other means. For example from KDE.org https://kde.org/community/whatiskde/kdefreeqtfoundation.php
It says if you want to install Qt binaries from Qt website. You can still distribute the binaries other means. For example from KDE.org https://kde.org/community/whatiskde/kdefreeqtfoundation.php
No, it just means they are hiding the "Skip" button in the Qt SDK installer.
https://i.stack.imgur.com/sEDMC.png
End-users don't have to install the Qt SDK.
https://i.stack.imgur.com/sEDMC.png
End-users don't have to install the Qt SDK.
I made a joke once that the Godot open-source game engine had 'accidentally' become an amazing alternative to Qt (Godot's own editor is itself a Godot application and quite nice for a desktop UI).
Notwithstanding what Qt offers in the embedded space, I think it's interesting to ask the question more seriously. For rich, cross-platform desktop applications, is a game engine a better choice than Qt?
Notwithstanding what Qt offers in the embedded space, I think it's interesting to ask the question more seriously. For rich, cross-platform desktop applications, is a game engine a better choice than Qt?
Does Godot support vector graphics?
Another good alternative would be JUCE. It's made for audio dev but it is crossplatform and has support for resolution independent UIs. It supports OpenGL and AFAIK Metal and Vulkan support are on the way.
https://juce.com/
Also Flutter will support desktop at some point.
Another good alternative would be JUCE. It's made for audio dev but it is crossplatform and has support for resolution independent UIs. It supports OpenGL and AFAIK Metal and Vulkan support are on the way.
https://juce.com/
Also Flutter will support desktop at some point.
Does either support IMEs, accessibility (across all platforms)?
There's more to a good modern UI toolkit than just drawing the GUI, and I don't mean the utility libs that used to be important but honestly aren't anymore, but things that are part of UI/UX like accessibility and apropriate integration with OS features for it.
There's more to a good modern UI toolkit than just drawing the GUI, and I don't mean the utility libs that used to be important but honestly aren't anymore, but things that are part of UI/UX like accessibility and apropriate integration with OS features for it.
Not sure but probably not. If accessibility and integration with the OS are important it's probably better to go with Cocoa and .NET/UWP instead of a crossplatform solution.
I imagine QT solves this as well but at $5000+ per developer per year it might make more sense to have 2 codebases with native UIs and shared code. I looked into that option recently and using Nim to transpile to C/C++ for the shared business logic/network/etc seemed like the best option.
I imagine QT solves this as well but at $5000+ per developer per year it might make more sense to have 2 codebases with native UIs and shared code. I looked into that option recently and using Nim to transpile to C/C++ for the shared business logic/network/etc seemed like the best option.
GTK, QT, wxWidgets all support accessibility. And Cocoa/UWP are not the end all, be all of platforms where one might want an accessible GUI program. Making three different GUI codebases is right out, IMO, for most cases I'm looking at, and libraries that have zero support for accessibility don't get a pass (thus I have no interest in any imgui solution, as they are inimical to accessible UI).
The news about Qt unfortunately mean I have to consider whether to put effort into upgrading the toolkit I have to Qt5 (or wait for Qt6 but still have a sword of damocles over me) :/
The news about Qt unfortunately mean I have to consider whether to put effort into upgrading the toolkit I have to Qt5 (or wait for Qt6 but still have a sword of damocles over me) :/
On desktop just using Qt under open-source terms is a pretty good option, unless you really need one of the GPL-licensed add-ons. The announced change for the LTS versions tries to make that a bit less attractive, but for many it's not going to be that much of an issue.
> Also Flutter will support desktop at some point.
Sciter (https://sciter.com) works on all desktops from the very beginning (10+ years already).
Sciter (https://sciter.com) works on all desktops from the very beginning (10+ years already).
A couple of months ago they implemented JSX and React like features:
https://sciter.com/developers/sciter-docs/reactor-and-ssx/
Unless I'm missing something it only seems to support reactive local component state a la this.setState().
https://sciter.com/developers/sciter-docs/reactor-and-ssx/
Unless I'm missing something it only seems to support reactive local component state a la this.setState().
What a wonderful effort to prevent Qt popularity from growing.
Read the title and thought "perhaps this is time to explore more into Qt, beyond the classic Qt widgets...". Read the news - "no, this seems more like time to forget about Qt altogether and explore the alternatives".
Read the title and thought "perhaps this is time to explore more into Qt, beyond the classic Qt widgets...". Read the news - "no, this seems more like time to forget about Qt altogether and explore the alternatives".
Which there are? Gtk3? Electron? I do not see any cross-platform gui toolkit which comes even close to Qt
Gtk3 obviously isn't an alternative as it's not really cross-platform (perhaps it is, I don't know for sure, but I haven't ever seen a single GTK3 app on Windows or on a Mac, there probably is a reason). Electron? Perhaps but it's ridiculously resource-hungry. What remains are wxWidgets and, maybe, Flutter.
GTK3 works decently well on those platforms but there are still minor bugs and compatibility issues. There is no reason for this other than that there hasn't been much interest among developers in keeping the backends up to date. Also, GTK3 recently hit maintenance mode and most developer activity has moved to GTK4.
If you want to stick with C++, wxWidgets.
If you don't mind using other languages, IMO LCL/Lazarus is superior to pretty much every other toolkit, including Qt.
Note that the above are for making desktop applications, not mobile applications nor anything relevant outside of the GUI side of a desktop application.
If you don't mind using other languages, IMO LCL/Lazarus is superior to pretty much every other toolkit, including Qt.
Note that the above are for making desktop applications, not mobile applications nor anything relevant outside of the GUI side of a desktop application.
Hmm. Sad about needing to log in to download anything. Seems like prioritising marketing KPIs over developer experience.
Anyway, not to be nitpicky or anything, but there is a typo on "feedback we can get _form_ the community" - otherwise I think it's actually positive to offer point releases on a periodic basis.
Anyway, not to be nitpicky or anything, but there is a typo on "feedback we can get _form_ the community" - otherwise I think it's actually positive to offer point releases on a periodic basis.
I have not been affected but I heard some teams where a QT rep was interested to understand how they were using QT. Skip fast forward 2 years later, they now have to pay QT licenses while they where using the open source version before.
It might have been a good business decision to get more support, or to use some non GPL components, but I can't help to think that the not so friendly push from the QT rep was also a reason...
So I got the feeling this is just another step in that same direction.
It might have been a good business decision to get more support, or to use some non GPL components, but I can't help to think that the not so friendly push from the QT rep was also a reason...
So I got the feeling this is just another step in that same direction.
> I have not been affected but I heard some teams where a QT rep was interested to understand how they were using QT. Skip fast forward 2 years later, they now have to pay QT licenses while they where using the open source version before.
Do you mean they weren't compliant with the open source license, or that the rep sold the commercial support?
Do you mean they weren't compliant with the open source license, or that the rep sold the commercial support?
Honestly, I don't exactly know so my answer is a bit vague. I believe they were compliant but I got the feeling from the discussion that the rep was pushing hard so that they get a commercial license, to not having to bother cherry picking only the GPL components and not having to display licenses and making the source code available. (which was done previously)
It is a bit strange that QT can at the same time boast about its open source roots, but in practice, discouraging its corporate users to use that license, which is understandable from a business perspective.
It is a bit strange that QT can at the same time boast about its open source roots, but in practice, discouraging its corporate users to use that license, which is understandable from a business perspective.
Your original comment sounded a bit negative towards Qt, but it sounds like either the company was not legally complying with the license (in which case Qt was owed some money) or the company found some benefit in the paid product. In either case, I'm not sure there's a way I would view it negatively (unless Qt changed licensing on some used components such that the company was in compliance in the past but ended up unknowingly not being compliant by the time the rep was talking with them).
Talking to a sales rep isn't always a bad thing. Sometimes they let you know interesting things that are for offer you didn't know about, but would have bought if you did (or can give you trials of things you've been interested in but unwilling to pull the trigger on because you weren't sure how it would work).
Talking to a sales rep isn't always a bad thing. Sometimes they let you know interesting things that are for offer you didn't know about, but would have bought if you did (or can give you trials of things you've been interested in but unwilling to pull the trigger on because you weren't sure how it would work).
My company has been a Qt partner for 10 years now. It’s embarrassing how many companies we met that were not complaining with the open source license — most of them did comply after they talked to us though. Our market (Italy) is specially allergic to runtime licenses (required for embedded products, which is 90% of what companies use Qt for, at least here) so they prefer to bend over for compliance rather than spending on a runtime license.
The ongoing thread on the Qt mailing list:
https://lists.qt-project.org/pipermail/development/2020-Janu...
https://lists.qt-project.org/pipermail/development/2020-Janu...
Qt is quickly rising to Delphi levels of unaffordability.
Seeing people freak out over this, it's typical Qt Company: Really, really bad at communicating changes properly. Yes, it's annoying, but far from the big deal people make it out to be.
>From February onward, everyone, including open-source Qt users, will require valid Qt accounts to download Qt binary packages.
Hopefully this doesn't include redistributed binaries. I really do like KDE.
Hopefully this doesn't include redistributed binaries. I really do like KDE.
> Note that source packages will still be available without a Qt account.
From the post. Once you download + rebuild, your binaries built from the OSS version can't have additional restrictions, otherwise they cease to be true GPL ...
From the post. Once you download + rebuild, your binaries built from the OSS version can't have additional restrictions, otherwise they cease to be true GPL ...
They changed the license from LGPL to GPL?
The core is LGPLv3, meaning that you can bundle precompiled versions and dynamically link against them at run-time provided that you provide means for your end-users to switch to their own version of the libraries.
Qt has various components under different licences. Some are GPL.
Oh? When did they add that? Sneaky. I'm not current with what's happening with Qt >=5.
With all the threats and restrictions and enterprise pricing for commercial licenses, it looks like Qt is heading towards Delphi levels of irrellevance.
With all the threats and restrictions and enterprise pricing for commercial licenses, it looks like Qt is heading towards Delphi levels of irrellevance.
A while back they added GPLv3 as an option for modules that used to only be available under the commercial license. They're listed here: https://doc.qt.io/qt-5/qtmodules.html#gpl-licensed-addons
Right, of course. Blanket scary statements like that make me nervous. Long live KDE. :)
Can't vouch for it, but there may be an alternative:
"CopperSpice is a set of individual libraries which can be used to develop cross platform software applications in C++. It is a totally open source project released under the LGPL V2.1 license and was initially derived from the Qt framework. Over the last several years CopperSpice has completely diverged, with a goal of providing a first class GUI library to unite the C++ community."
https://www.copperspice.com
"CopperSpice is a set of individual libraries which can be used to develop cross platform software applications in C++. It is a totally open source project released under the LGPL V2.1 license and was initially derived from the Qt framework. Over the last several years CopperSpice has completely diverged, with a goal of providing a first class GUI library to unite the C++ community."
https://www.copperspice.com
"Installation of Qt binaries will require a Qt Account"
Farewell, Qt.
Farewell, Qt.
Won't sudo apt install qtcreator still work? Just use your distro packages.
Sure but they will not contain the most recent versions of Qt/QtCreator. Also many of us Qt developer still need to develop Windows specific stuff... I guess vcpkg is the way to go here.
What would be funny though if someone would setup a CI for Qt/QtCreator and distribute the binaries via a custom version of their open source installer framework (which is basically the maintenance tool). So just like before. When enough people switch to this tool maybe the qt company would stop forcing logins.
What would be funny though if someone would setup a CI for Qt/QtCreator and distribute the binaries via a custom version of their open source installer framework (which is basically the maintenance tool). So just like before. When enough people switch to this tool maybe the qt company would stop forcing logins.
> if someone would setup a CI for Qt/QtCreator and distribute the binaries
Actually this reminds me how Oracle started distributing JRE through proprietary terms for non-personal use. It led to people creating third party GPL builds. Now they can't even bundle the ask! toolbar any more because people use a different installer :).
Actually this reminds me how Oracle started distributing JRE through proprietary terms for non-personal use. It led to people creating third party GPL builds. Now they can't even bundle the ask! toolbar any more because people use a different installer :).
$499 for small companies and startups.
QT is finally understanding their pricing was totally wrong.
QT is finally understanding their pricing was totally wrong.
This price includes the use of the full Qt for Device Creation product, but not any distribution licenses – these need to be agreed separately. It also includes only installation support, whereas a regular commercial license comes with full support.
What do they mean, no distribution licenses? For 500/year I can develop but not sell? :)
What do they mean, no distribution licenses? For 500/year I can develop but not sell? :)
Yes, that's my understanding. A "distribution license" allows you to actually sell an instance of your product under the commercial licensing agreement.
But why would I develop if i can't sell? If i do open source, I have no need for a license. If i don't, the 500/year option is useless?
Plenty of companies develop desktop software for internal use. They built it, update it, and use it heavily but never sell it. I'm not sure how many of these fall into Qt's startup/small business category, though.
It seems like this license is maybe ideal for a small company that wants commercially-supported Qt to use while developing a product prior to selling it?
That seems like a fairly small niche to target, but presumably they're making this change based on actual usage data and not just conjuring it out of thin air.
It seems like this license is maybe ideal for a small company that wants commercially-supported Qt to use while developing a product prior to selling it?
That seems like a fairly small niche to target, but presumably they're making this change based on actual usage data and not just conjuring it out of thin air.
As mentioned elsewhere, it's mainly about Qt for device creation. Not for regular desktop apps. For device creation you'll very likely need the commercial version to get platform support.
Is that a new thing invented to go with this start-up licence? I can't see any reference to distribution licences elsewhere in their pricing material.
It seems... eccentric... to make a public announcement of the price of a new licence, then mention that in order to actually use it you'll need to buy another licence as well whose price you aren't publishing.
It seems... eccentric... to make a public announcement of the price of a new licence, then mention that in order to actually use it you'll need to buy another licence as well whose price you aren't publishing.
No, "distribution licenses" are very common in this type of commercial software for embedded systems market. If you talk to Wind River, QNX, OpenRTOS, Qt, Crank, or any of the numerous software tool vendors for commercially-supported embedded software, there will be a "development license" which you pay to license the tooling, source code and precompiled binaries, plus a per-unit "distribution license" to actually sell their product as a component of your product. The pricing is usually really reasonable compared to your per-unit BOM cost and expected production quantities.
> No, "distribution licenses" are very common in this type of commercial software for embedded systems market
So does this whole topic apply only to embedded systems then? I am a Qt developer who has bought Qt licences in the distant past, but I know nothing about embedded systems, so that would explain why we seem to be talking at cross purposes as well as why I found the original post so puzzling.
For desktop & mobile applications, I can go to qt.io, ask to buy a Qt licence, and be quoted straight away a per-developer annual fee with no reference to any separate distribution licence. What I'm wondering is whether this will also be the case for the new micro-business tier, or whether it introduces some requirement for a separate distribution licence that the normal application development licence does not have.
Edit: I see now that I have completely mis-read the original post. It says that the micro-business tier offers a licence for "Qt for Device Creation", not for Qt in general. So it probably isn't available at all for desktop & mobile applications. I'm sorry for wasting your time.
So does this whole topic apply only to embedded systems then? I am a Qt developer who has bought Qt licences in the distant past, but I know nothing about embedded systems, so that would explain why we seem to be talking at cross purposes as well as why I found the original post so puzzling.
For desktop & mobile applications, I can go to qt.io, ask to buy a Qt licence, and be quoted straight away a per-developer annual fee with no reference to any separate distribution licence. What I'm wondering is whether this will also be the case for the new micro-business tier, or whether it introduces some requirement for a separate distribution licence that the normal application development licence does not have.
Edit: I see now that I have completely mis-read the original post. It says that the micro-business tier offers a licence for "Qt for Device Creation", not for Qt in general. So it probably isn't available at all for desktop & mobile applications. I'm sorry for wasting your time.
For companies earning under $100000 a year. That's pretty meager for a company employing up to 5 people. Qt is a great environment, but it is still ridiculously expensive for small companies.
For what it does, I don't think so, seems like a bargain.
If you have more than 5 employees or make more than $100k/year (i.e. even in a low wages section of the US, you pay more than one developer) - it's the old price of $5500/year/developer.
That's lot of money per dev.
Yeah wait a minute - 100k USD a year is barely one developer (Especially after benefit costs, etc) - and they say revenue too.
So basically if you're a one man shop it's an improvement I guess?
So basically if you're a one man shop it's an improvement I guess?
According to their 2018 report they have 45.6M EUR in sales and loss of 2322 Euro. No idea where the 100k ist coming from.
https://mb.cision.com/Main/14183/2742082/991814.pdf (host blocked by uBlock for me)
https://mb.cision.com/Main/14183/2742082/991814.pdf (host blocked by uBlock for me)
They were referring to the new Qt license. Companies with less than $100k in revenue and less than five employees now only have to pay $499/year for a Qt commercial license.
It's basically a license for a tiny hardware startup to do Qt development with some limited support. It's not a very good license to sell product with, since any hardware startup that intends to use Qt in a product will pre-negotiate the distribution licenses up-front to capture the cost in the BOM for a unit. The only thing this does is allows you to ramp your commercial license costs as you get closer to profitability.
Basically if I'm a hardware company A, and I want to build a device that uses Qt5, originally I would buy a commercial license up-front for like 5 figures. If I'm building this product using my own personal funds and not VC-funding then this represents a huge outlay to get commercial support. What this $500 fee does is allows me to do commercial-licensed development out of the gate but without any support resources beyond installation(which was easy). Then, when I start doing design verification and am fixing bugs in the product I can start paying for a full commercial license and get support if I discover an issue with the graphics engine.
Getting Qt up and running can be difficult if you've never done any open-source or Linux development before. And for some systems, having installation support is paramount because the build systems are not tightly integrated with Qt's build system(EG QNX). So it can ease some difficulties in using Qt.
I think this is a pretty good offering for a niche of users who would otherwise avoid all the GPLv3 code and stick to Qt core, develop alternatives to all the good Qt modules like the virtual keyboards and stuff, and then determine they don't need to pay for a full commercial license once they get up and running. This provides an alternative path for those users where they can feel comfortable just using Qt's version of certain things. And it's probably a big win for them.
Basically if I'm a hardware company A, and I want to build a device that uses Qt5, originally I would buy a commercial license up-front for like 5 figures. If I'm building this product using my own personal funds and not VC-funding then this represents a huge outlay to get commercial support. What this $500 fee does is allows me to do commercial-licensed development out of the gate but without any support resources beyond installation(which was easy). Then, when I start doing design verification and am fixing bugs in the product I can start paying for a full commercial license and get support if I discover an issue with the graphics engine.
Getting Qt up and running can be difficult if you've never done any open-source or Linux development before. And for some systems, having installation support is paramount because the build systems are not tightly integrated with Qt's build system(EG QNX). So it can ease some difficulties in using Qt.
I think this is a pretty good offering for a niche of users who would otherwise avoid all the GPLv3 code and stick to Qt core, develop alternatives to all the good Qt modules like the virtual keyboards and stuff, and then determine they don't need to pay for a full commercial license once they get up and running. This provides an alternative path for those users where they can feel comfortable just using Qt's version of certain things. And it's probably a big win for them.
Not a win for them at all. Still have to do a legal distribution negotiation. So how would this help them ? It'll help them pay $500 a year more, that's all and that's the point of this change. Nothing more.
Parent laid it out already: without this option, device creators would need the full commercial license right from the start. This allows them to cheaply bootstrap and get the full license if/when their gadget proves promising.
[deleted]
Yes, for the things that QT does, it was extremely cheap.
[deleted]
> From February onward, everyone, including open-source Qt users, will require valid Qt accounts to download Qt binary packages. We changed this because we think that a Qt account lets you make the best use of our services and contribute to Qt as an open-source user.
It is quite annoying to get these thinly-veiled pseudo-reasons for forcing people to login to get the download. Surely they just want to know names and affiliations of who downloads their open source versions.
That's understandable from a business perspective, but then please don't put some bullshit there about needing to register at download time to do code reviews and contribution.
It is quite annoying to get these thinly-veiled pseudo-reasons for forcing people to login to get the download. Surely they just want to know names and affiliations of who downloads their open source versions.
That's understandable from a business perspective, but then please don't put some bullshit there about needing to register at download time to do code reviews and contribution.
I initially scoffed at your comment, but I played it out in my head. "We changed this because we aim in the next few years to shift to a subscription-based model, and this is the first step required in the transition" really does sound a lot less condescending and makes sense.
What shift?
It's my understanding that Qt had subscription based model for a long time. Commercial Licenses are sold for time and developer seat.
It's my understanding that Qt had subscription based model for a long time. Commercial Licenses are sold for time and developer seat.
That quote was just as an example. I don't really know what the business reasoning behind this change is.
It does explicitly state this in the blog:
"It also allows us to initiate a dialogue with commercial companies who mostly work with open-source versions of Qt."
Open source is free lunch. You pay for it by engaging with the community. So requiring nothing except a login for binaries, which does come at an actual cost for the company providing them, is a pretty fair deal.
"It also allows us to initiate a dialogue with commercial companies who mostly work with open-source versions of Qt."
Open source is free lunch. You pay for it by engaging with the community. So requiring nothing except a login for binaries, which does come at an actual cost for the company providing them, is a pretty fair deal.
Or put another way, we want relationships with our users. There's lots of ways that could play out, including money, but it's not surprising at all that a business wants to know who its customers and potential customers are. Next.
You are absolutely right, but in the light of how these "register to download" changes played out in almost every case we have every reason to be cynical IMO...
You want money. Next.
[deleted]
I do find some of these changes annoying, but not particularly life-threatening. The use of a Qt account to download pre-built binaries by not being allowed to press skip will be annoying, but realistically speaking how often are you doing that? If you need them for CI, then you should (in my small world) be downloading once and hosting them yourself.
With regards to LTS binaries, it is unfortunate, but we’ll still be able to grab sources from Git and (hopefully) their download site to rebuild patch versions from source.
The other note that sticks out is the cheaper license for the Device Creation kit. This is for embedded systems, not general applications which I haven’t seen anyone mention.
With regards to LTS binaries, it is unfortunate, but we’ll still be able to grab sources from Git and (hopefully) their download site to rebuild patch versions from source.
The other note that sticks out is the cheaper license for the Device Creation kit. This is for embedded systems, not general applications which I haven’t seen anyone mention.
> With regards to LTS binaries, it is unfortunate
I think this actually applies to LTS sources as well, which is even more unfortunate. Though, their response to this question on the mailing list was rather unclear.
I think this actually applies to LTS sources as well, which is even more unfortunate. Though, their response to this question on the mailing list was rather unclear.
My read of this is that you're free to continue to build and distribute your own binaries, but those won't be able to participate in the plugin ecosystem. The effect of this change depends on the value of the plugin service. I mean, it could be great. I certainly hope it's great for the Qt project.
Does there exist a CentOS equivalent of Qt?
This dude re-builds/backports Qt for Ubuntu, someone could do the same for rhel/centos.
https://launchpad.net/~beineri
https://launchpad.net/~beineri
The official Qt installer supports CentOS (useful if you want the most recent version of Qt without compiling from source), and it also optionally provides a more recent version of OpenSSL necessary for QtWebEngine and possibly other applications.
https://github.com/qt
Source is available.
Source is available.
Qt is included in many GNU/Linux distros. On ubuntu you can just do sudo apt install qtcreator.
Maybe copperspice as mentioned by "icandoit":
https://news.ycombinator.com/item?id=22161633
But maybe that's more as Suse is to RedHat than CentOS is to RedHat..
https://www.copperspice.com/
https://news.ycombinator.com/item?id=22161633
But maybe that's more as Suse is to RedHat than CentOS is to RedHat..
https://www.copperspice.com/
I don't think that Qt is unavailable in CentOS.
I think he meant an alternate build from source packages ( Like Centos to Redhat)
I think you've misunderstood the question - they were asking if there was an alternative packaging and support provider for the open source versions of Qt.
I did feel something was afoot when a KDE developer blogged a warning shot about the terms of their agreement: https://news.ycombinator.com/item?id=21755337
> Installation of Qt binaries will require a Qt Account
I've used Qt in professional environments with commercial licensing at previous gigs. I'd considered using Qt for personal projects using their open source licensing. But this is a killer requirement. Goodbye, Qt.
I've used Qt in professional environments with commercial licensing at previous gigs. I'd considered using Qt for personal projects using their open source licensing. But this is a killer requirement. Goodbye, Qt.
I’ve also been a longtime fan of Qt, who has both argued for it and defended it in discussions, as well as used it in a startup I founded and in a separate commercial contract project. But this news means that I likely won’t use it again and certainly won’t recommend it anymore.
Yep. Qt used to be THE answer. Now it's not.
It's an inconvenience, but it's a requirement for the developer and not the end user. Hardly the main criteria when selecting your framework is it?
Problem is, if you check out qt.io you'll get an almost Oracle like impression. That is, "don't go near us unless you have a full time legal department".
"Download the open source version if you're sure you can comply with the LGPL" is just a threat, pure and simple.
Thus, I wouldn't touch Qt in a commercial venture that is too small to have full time legal counsel on hand.
5500/year/developer is significant just about everywhere outside Silicon Valley.
[Editing comment because we're over HN's threading limits] @avamander:
But who decides that I've complied with the LGPL? Do you think it's as simple as dynamically linking with their provided binaries and making public any patches to Qt? I don't think so. It smells to me that if they decide you owe them money, there'll be a lawsuit coming.
"Download the open source version if you're sure you can comply with the LGPL" is just a threat, pure and simple.
Thus, I wouldn't touch Qt in a commercial venture that is too small to have full time legal counsel on hand.
5500/year/developer is significant just about everywhere outside Silicon Valley.
[Editing comment because we're over HN's threading limits] @avamander:
But who decides that I've complied with the LGPL? Do you think it's as simple as dynamically linking with their provided binaries and making public any patches to Qt? I don't think so. It smells to me that if they decide you owe them money, there'll be a lawsuit coming.
I don't find it a loss if you can't comply with libre software's licenses and don't then use them illegally. I am also glad Qt makes it clear that licenses should be respected.
That sounds bad, but what does it even mean?
They won't be able to prevent e.g. debian from distributing a `qt5-xyz-dev` package for example, no?
Can you explain why this is such a problem? The way I read it it's for development, not distribution.
Not everyone's development environment is connected to the Internet.
Additionally, trying to compile the project from source is extremely painful compared to most projects: it's not really possible in any obvious way to duplicate the output of the binary distribution without looking at the guts of Qt's continuous integration environment for weeks on end.
Additionally, trying to compile the project from source is extremely painful compared to most projects: it's not really possible in any obvious way to duplicate the output of the binary distribution without looking at the guts of Qt's continuous integration environment for weeks on end.
For Linux distributions and even Homebrew on Mac OS nothing will change as they're not using "official binaries".
If you are willing to use older releases (which can be absolutely fine)
Used Qt with Python a lot, 6 or 7 years ago. Their API's are really great. It's farewell I guess.
LTS and offline installer to become commercial-only
"All you freeloaders will become the test monkeys for our actual paying customers" :)
"All you freeloaders will become the test monkeys for our actual paying customers" :)
What is an 'offering'? Does it mean the licence agreement, or the product, or the pricing plan?
I don't know this business terminology.
I don't know this business terminology.
[deleted]
They've just broke the existing support from Conan recipes.
What a badass move
What a badass move
How so?
you need an online account to download the package
Well, that's what the announcement is about, but a) that's not in effect yet and b) shouldn't the conan packages be built from source anyway?
Also, are you talking about https://github.com/bincrafters/conan-qt or anything else?
Also, are you talking about https://github.com/bincrafters/conan-qt or anything else?
Is it legal to torrent. Not that i care about. Forget it. Bye Qt
With this move they will be considerably shrinking their developer base since a large, if not most, are enthusiasts of open source. Many frameworks made the same mistake in the past and now they're restricted to a small niche or have fallen into oblivion.
Other sites and organizations can compile and distribute the binaries.
KDE Free Qt Foundation -The KDE Free Qt Foundation is an organization with the purpose of securing the availability of the Qt toolkit https://kde.org/community/whatiskde/kdefreeqtfoundation.php