A Better Qt Because of Open Source and KDE(olafsw.de)
olafsw.de
A Better Qt Because of Open Source and KDE
http://www.olafsw.de/a-better-qt-because-of-open-source-and-kde/
124 comments
Qt is massive, I doubt small communities would rush to integrate it and make it their job to maintain it all...
I doubt anyone in OSS communities is seriously deterred from using Qt because of the LGPL. It’s just a very big and very complex project that requires a lot of manpower to “tame”.
I doubt anyone in OSS communities is seriously deterred from using Qt because of the LGPL. It’s just a very big and very complex project that requires a lot of manpower to “tame”.
I guess it depends on how much of Qt you need. If you just need the basics you can import mainly what you need[0]. In the case of D though one of it's focuses is to work well with C++ directly. I'm not talking about maintaining it all, I'm talking about embedding it directly into the standard library of a programming language.
I guess you do make a fair point in regards to the LGPL though.
[0]: Here's an example of someone building only a minimal amount of Qt: https://github.com/dirtycold/qt-minimal-build
I guess you do make a fair point in regards to the LGPL though.
[0]: Here's an example of someone building only a minimal amount of Qt: https://github.com/dirtycold/qt-minimal-build
Already happened: https://www.copperspice.com
But that is not BSD
Thanks for the hint. Didn't know it. As it seems it is no longer Qt. They once started with Qt (don't know which version) but they have "completely diverged" as they say. The goal is not to have a free Qt but to have "Extensive use of modern C++ functionality" (with all these buzzwords). Not even shure if their containers are still implicitly shared. Will even though continue to have a look at it.
> don't know which version
apparently, they forked from Qt 4.8 and QML is disabled in Copperspice. Ref:
https://www.copperspice.com/docs/cs_overview/timeline.html#t...
https://news.ycombinator.com/item?id=9685022
https://forum.copperspice.com/viewtopic.php?f=11&t=1152
apparently, they forked from Qt 4.8 and QML is disabled in Copperspice. Ref:
https://www.copperspice.com/docs/cs_overview/timeline.html#t...
https://news.ycombinator.com/item?id=9685022
https://forum.copperspice.com/viewtopic.php?f=11&t=1152
It's not as big as Linux, Chromium, Dart and others. All of my projects are still compatible with C++ Qt 4. I'm able to and I will maintain it as soon as someone is estabilshing a free fork; up to now I'm being held back by this outrageous Contributor Agreement.
A lot of unnecessary complexity started with all the JavaScript stuff. This can be replaced by the other existing (and free) scripting language bindings. So yes, I don't see any problem to continue maintenance of the Qt framework without the Qt company at all.
I didn't think D had SQLite in stdlib. When I googled for it recently I just found some single contributor package and assumed it wasn't super well maintained.
That might be why honestly.
https://dlang.org/phobos/etc_c_sqlite3.html
For anybody's reference, it also has zlib, and an ODBC library.
https://dlang.org/phobos/etc_c_sqlite3.html
For anybody's reference, it also has zlib, and an ODBC library.
Is there a page on how to use it? Thanks for the link!
Unfortunately I do not have any handy resources. I would look at some of the SQLite implementations you saw to confirm if they are just using the builtin SQLite. This seems to be mapping to SQLite code itsef instead of a more higher level driver.
Edit:
Did find this topic on the D forums:
https://forum.dlang.org/thread/[email protected]...
Edit:
Did find this topic on the D forums:
https://forum.dlang.org/thread/[email protected]...
I found that too awhile back. Compare that with even other obscure languages like Nim and you'll see why it makes me hesitate. I really want to like D, but it is missing support for a few things I reach for often. Chicken and the egg problem.
Yeah I heard you, this is also why sometimes I just go and use Go. I think D is perfectly nice in regards to the language itself, but it could use some polish and a few minor additions.
I love that with Go I can do systems application development (think web, mail, etc). I wish D would just have a built-in web module / package. Vibe.d is nice and all, but built-in is better.
I love that with Go I can do systems application development (think web, mail, etc). I wish D would just have a built-in web module / package. Vibe.d is nice and all, but built-in is better.
The behavior of the Qt company lately is a bit troubling.
First, the core can be licensed under Commercial or LGPL licensing. This let's non-paying developers use the core in commercial software. This policy was established to ensure trust with the community during one of the many company transitions. For all new modules, Qt evades that requirement by licensing under Commercial or GPL. I have mixed feelings on this.
Second and more importantly, they have started sending aggressive audit letters to customers. I guess that makes sense from a bean-counter point of view where you poke the customer and try to get them to buy more licenses either because the customer actually needs the licenses, or because the customer is afraid to let any dev work without paying protection money. This is a huge pain in the neck for me as a paying customer. They even sent the aggressive audit letter to an old license we have that had not been renewed (or used) in around a decade.
I'll definitely be rethinking my relationship as a customer when the next renewal comes up.
First, the core can be licensed under Commercial or LGPL licensing. This let's non-paying developers use the core in commercial software. This policy was established to ensure trust with the community during one of the many company transitions. For all new modules, Qt evades that requirement by licensing under Commercial or GPL. I have mixed feelings on this.
Second and more importantly, they have started sending aggressive audit letters to customers. I guess that makes sense from a bean-counter point of view where you poke the customer and try to get them to buy more licenses either because the customer actually needs the licenses, or because the customer is afraid to let any dev work without paying protection money. This is a huge pain in the neck for me as a paying customer. They even sent the aggressive audit letter to an old license we have that had not been renewed (or used) in around a decade.
I'll definitely be rethinking my relationship as a customer when the next renewal comes up.
Its weird what people and businesses will and will not support.
Businesses will shovel loads of money into SaaS and cloud hosting without blinking, but support a programming tool? Never! Another hundred Office users and 50 more AWS VMs? No problem.
People will spend $10 on a coffee but would never spend $5 to support a project that saves them hundreds or thousands of hours of work. They'll spend $15/month to host a site, but would never pay for the software that runs it even though that took far more effort than racking up some servers.
No wonder everything is surveillanceware and mega-corp silos. We get what we pay for, or rather we don't get what we won't pay for... like independent software.
Businesses will shovel loads of money into SaaS and cloud hosting without blinking, but support a programming tool? Never! Another hundred Office users and 50 more AWS VMs? No problem.
People will spend $10 on a coffee but would never spend $5 to support a project that saves them hundreds or thousands of hours of work. They'll spend $15/month to host a site, but would never pay for the software that runs it even though that took far more effort than racking up some servers.
No wonder everything is surveillanceware and mega-corp silos. We get what we pay for, or rather we don't get what we won't pay for... like independent software.
Sure. In the case of Qt, it was very expensive but well worth paying for because it does a good job. The LGPL stuff is important because it provides us with an "out" if the Qt company goes crazy with prices.
Avoiding the "out" makes me not want to make use of the new modules. And the hassle of audits makes be question the cost of the inconvenience to me, the dev, of having a license.
It's tradeoffs all the way down.
Avoiding the "out" makes me not want to make use of the new modules. And the hassle of audits makes be question the cost of the inconvenience to me, the dev, of having a license.
It's tradeoffs all the way down.
It's outrageously expensive. And you can't just buy what you really need, just all or nothing. In many projects I only need Qt Core; for that I would have to buy a license for everything from these people with a far worse contract than LGPL and pay royalties. No thanks.
Exactly, that is why you can only have nice tools when working for big corps.
FOSS made it fashionable to want to be paid for work, while refusing to pay for the work of others, and in the process using clunky tools.
Naturally upstream cannot pay bills from PR and eventually moves on.
FOSS made it fashionable to want to be paid for work, while refusing to pay for the work of others, and in the process using clunky tools.
Naturally upstream cannot pay bills from PR and eventually moves on.
I wouldn't take it that far, but IMHO the free (as in beer) part needs to be questioned at least when it comes to for-profit commercial uses of software.
I'd like software to be free and open source for people and academic or non-profit uses, but I would like it if corporations for their use if they are using them in certain ways. Particularly problematic is the use of FOSS to power closed SaaS.
ZeroTier (of which I am the founder) just adopted the BSL toward this end, but the BSL isn't perfect. I think a better sort of license and maybe one more compatible with traditional FOSS needs to be developed. I'm chatting with a few people.
I'd like software to be free and open source for people and academic or non-profit uses, but I would like it if corporations for their use if they are using them in certain ways. Particularly problematic is the use of FOSS to power closed SaaS.
ZeroTier (of which I am the founder) just adopted the BSL toward this end, but the BSL isn't perfect. I think a better sort of license and maybe one more compatible with traditional FOSS needs to be developed. I'm chatting with a few people.
I think what ZeroTier is doing is totally reasonable, and more companies who aspire to make money from open source should do it. One thing I especially like about ZeroTier's approach is that you publish a standard price list for your commercial license.
LGPL was decided by Nokia who bought the IP from Trolltech for ~150 Mio $ and also came up for the development costs up to Qt 5.1. Digia and The Qt Company "bought" the IP for about 5 Mio $ from Nokia and now earn money with commercial licenses of a library where the most important development steps were already done before. According to the commit logs the contribution rate of Nokia was at ~80%, wheras the Qt Company is rather at ~40% and with focus on stuff they can sell. I regularly meet people who bought a licence to use the Qt framework not realizing that they could use it under LGPL. I know the wording of the commercial license. It places the licensee clearly worse than with the LGPL variant. Personally, I find the business practices of this company, which have been observed for some time, rather questionable.I had a commercial license with Trolltech, which cost me a lot of money. As soon as LGPL was available, I cancelled the contracts and avoided projects that could not be done with LGPL rather than signing such a single-edge contract with this company.
> commercial software
I think (could be wrong) you meant to imply closed-source, as one can have commercial open-source software.
I’m not a huge fan of them using GPL for their newer modules, either, like charts. It seemed a bit unnecessary other than driving those who don’t like/can’t use the GPL license into a dev subscription.
I think (could be wrong) you meant to imply closed-source, as one can have commercial open-source software.
I’m not a huge fan of them using GPL for their newer modules, either, like charts. It seemed a bit unnecessary other than driving those who don’t like/can’t use the GPL license into a dev subscription.
Which is quite fair, they have to live from something.
https://www.qt.io/licensing/
Commercial, GPL or LGPLv3 are available, which means they are going after embedded customers who typically don't want to open up their hardware (TVs, Cars, etc). Anybody else is free to reap the benefits, even for developing a commercial app on desktop (granted, that's a tough enough market to crack already these days).
As the parent explicitly stated, not all components are available under LGPL.
Sadly, I fear Digia (and its owned spin-off, the Qt Company) will be the death of Qt:
Unlike Nokia, which bought Qt and opened it to a more liberal license (LGPLv2.1) because it saw it as a strategic platform basis to attract developers to its platform (that is, until the MS shill Elop was injected as Nokia's CEO and destroyed the company… and sold Qt off)…
… unlike Nokia, the Digia-owned "Qt Company" (now publicly traded as QT-COM on Nasdaq Helsinki) sees Qt as a direct revenue source to monetize to the maximum and developers as milk cows to maximally squeeze out as long as possible. And unlike Nokia, Digia's "Qt Company" does so in a quite unsustainable way. They enormously increased the prices of commercial licenses to a level that can only be qualified as extortion, and they do whatever possible to force developers out of LGPL and into Pay-to-Play:
they switched Qt's open source edition from LGPLv2.1 to LGPLv3… and they switched from LGPL to GPL or commercial only for most new modules, including QtQuick 3D.
The bottom line is: it's really going down the drain, and lots of developers of Qt-based programs and apps are drawn away and looking for something new. The need for a new modern and more liberally licensed cross-platform UI lib is bigger than ever.
Also, many devs are even switching out of Qt-based cross-platform development and back to separate codebases for OS-dependent native UI toolkits… which is kinda sad, though partly alleviated by some other factors (such as the similarities between Swift and Kotlin)
Unlike Nokia, which bought Qt and opened it to a more liberal license (LGPLv2.1) because it saw it as a strategic platform basis to attract developers to its platform (that is, until the MS shill Elop was injected as Nokia's CEO and destroyed the company… and sold Qt off)…
… unlike Nokia, the Digia-owned "Qt Company" (now publicly traded as QT-COM on Nasdaq Helsinki) sees Qt as a direct revenue source to monetize to the maximum and developers as milk cows to maximally squeeze out as long as possible. And unlike Nokia, Digia's "Qt Company" does so in a quite unsustainable way. They enormously increased the prices of commercial licenses to a level that can only be qualified as extortion, and they do whatever possible to force developers out of LGPL and into Pay-to-Play:
they switched Qt's open source edition from LGPLv2.1 to LGPLv3… and they switched from LGPL to GPL or commercial only for most new modules, including QtQuick 3D.
The bottom line is: it's really going down the drain, and lots of developers of Qt-based programs and apps are drawn away and looking for something new. The need for a new modern and more liberally licensed cross-platform UI lib is bigger than ever.
Also, many devs are even switching out of Qt-based cross-platform development and back to separate codebases for OS-dependent native UI toolkits… which is kinda sad, though partly alleviated by some other factors (such as the similarities between Swift and Kotlin)
FOSS developers leeching Qt developers will be the death of Qt.
It is hard to sustain a business out of donations and patreons, not everyone enjoys counting pennies every month.
Also Qt is doing pretty well, thanks to enterprises, which still seem to value paying for developer tooling.
It is hard to sustain a business out of donations and patreons, not everyone enjoys counting pennies every month.
Also Qt is doing pretty well, thanks to enterprises, which still seem to value paying for developer tooling.
Digia does not own Qt Company. Digia was clenly split in 2016. Digia owners received QTCOM stock. see:
https://www.morningstar.com/stocks/xhel/qtcom/ownership
Btw. Your claim that developers are switching is not true either. Qt use is increasing and it shows in the number of buying customers.
Btw. Your claim that developers are switching is not true either. Qt use is increasing and it shows in the number of buying customers.
> Qt use is increasing and it shows in the number of buying customers.
As if that was of any relevance to the question whether many Qt developers are switching. Given that commercial licenses are only used by a very small minority of the professional developers using Qt (most using open source Qt), themselves only a subset of all developers using Qt… the fact that that small minority is currently increasing while remaining a small minority… doesn't say anything about the proportion of still Qt using developers switching away.
Besides, the sustainability of a temporary increase of that minority is highly questionable. Of course QTCOM's pressure towards Pay-to-Play temporarily forces some of those who are still tied by all of their still-Qt-based code to buy Qt licenses as long as they haven't finished switching to a better alternative… but on the long term most of them quit too. Precisely because of that.
We'll see how that strategy of maximal monetization and maximally squeezing developers works out for QTCOM in the long term
As if that was of any relevance to the question whether many Qt developers are switching. Given that commercial licenses are only used by a very small minority of the professional developers using Qt (most using open source Qt), themselves only a subset of all developers using Qt… the fact that that small minority is currently increasing while remaining a small minority… doesn't say anything about the proportion of still Qt using developers switching away.
Besides, the sustainability of a temporary increase of that minority is highly questionable. Of course QTCOM's pressure towards Pay-to-Play temporarily forces some of those who are still tied by all of their still-Qt-based code to buy Qt licenses as long as they haven't finished switching to a better alternative… but on the long term most of them quit too. Precisely because of that.
We'll see how that strategy of maximal monetization and maximally squeezing developers works out for QTCOM in the long term
Your QT losing users is still unsubstantiated.
Developers stop using Qt for good technical reasons in projects that don't require the unique features of Qt. Qt's strength is being multiplatform. It works in embedded and realtime operating systems. It's not even useful for scrape by contract workers who do better with free web framework/UI stuff. Your TV, car, Television, have Qt in them. Its in medical devices and industry automation.
Qt may lose market share for Adobe PhoneGap, React Native, Flutter, Xamarin but that's because those target restrictive subset of what Qt is good for. Again, it's for good technical reasons. Nothing to do with licenses or Qt being evil company.
Developers stop using Qt for good technical reasons in projects that don't require the unique features of Qt. Qt's strength is being multiplatform. It works in embedded and realtime operating systems. It's not even useful for scrape by contract workers who do better with free web framework/UI stuff. Your TV, car, Television, have Qt in them. Its in medical devices and industry automation.
Qt may lose market share for Adobe PhoneGap, React Native, Flutter, Xamarin but that's because those target restrictive subset of what Qt is good for. Again, it's for good technical reasons. Nothing to do with licenses or Qt being evil company.
It just so happens that the biggest part of my work is in embedded. And while it's obvious that QTCOM is trying to establish itself in that domain… this here is merely wishful thinking:
> Your TV, car, Television, have Qt in them
no, actually neither has. And let's face it: while QTCOM does have clients in those domains… it doesn't have any huge share in either. Most use simpler lower-level graphical libs. Apart from that, you'll notice that those are Domains that account for a small minority of embedded… and a very unrepresentative one in that TVs, cars and TVs, unlike most of the embedded market, are stuff that are built by big corporations. So yeah, QTCOM seems to just focus on those big fish only now, as opposed to Nokia's strategy. As for industrial automation: don't make me laugh. Qt is totally irrelevant there.
And yes, licensing problems ARE a good reason which is a sore point, ESPECIALLY in embedded (where in most use cases you can't just dynamically link for LGPLv3 like on a desktop but have the whole mess of the build chain and update management if you are to let the user replace the Qt version).
> Your TV, car, Television, have Qt in them
no, actually neither has. And let's face it: while QTCOM does have clients in those domains… it doesn't have any huge share in either. Most use simpler lower-level graphical libs. Apart from that, you'll notice that those are Domains that account for a small minority of embedded… and a very unrepresentative one in that TVs, cars and TVs, unlike most of the embedded market, are stuff that are built by big corporations. So yeah, QTCOM seems to just focus on those big fish only now, as opposed to Nokia's strategy. As for industrial automation: don't make me laugh. Qt is totally irrelevant there.
And yes, licensing problems ARE a good reason which is a sore point, ESPECIALLY in embedded (where in most use cases you can't just dynamically link for LGPLv3 like on a desktop but have the whole mess of the build chain and update management if you are to let the user replace the Qt version).
You realize that Qt is dual licensed?
If you work in embedded like me, you already know that we make actual money. Nobody cares about license cost of Qt. It's quite low compared to everything else. We don't use LGPLv3 in Qt. We buy commercial license.
If you work in embedded like me, you already know that we make actual money. Nobody cares about license cost of Qt. It's quite low compared to everything else. We don't use LGPLv3 in Qt. We buy commercial license.
> You realize that Qt is dual licensed
what part of the thread did you not read? We've covered that already: the other option is the closed commercial license which since the switch from Nokia to QTCOM has become exorbitantly expensive
> Nobody cares about license cost of Qt (…) We don't use LGPLv3 in Qt. We buy commercial license.
You sound like you work in Qt Marketing, not in embedded.
> It's quite low compared to everything else
That's rather ridiculous. Most alternatives cost zero.
what part of the thread did you not read? We've covered that already: the other option is the closed commercial license which since the switch from Nokia to QTCOM has become exorbitantly expensive
> Nobody cares about license cost of Qt (…) We don't use LGPLv3 in Qt. We buy commercial license.
You sound like you work in Qt Marketing, not in embedded.
> It's quite low compared to everything else
That's rather ridiculous. Most alternatives cost zero.
I hope the BSD case happens soon before these people scare all the developers away.
Yes, exactly. You have my vote and my support in case the Qt framework will be forked based on the LGPL 2 versions and continued from there independently of the Qt Company.
Here some figures: Nokia bought Trolltech and thus the intellectual property of Qt 4 for around 100 million Euros, and then released it to the public under LGPL. Nokia also payed for the development of Qt 4.4 to 5.0, and then "sold" everything to Digia for a piece of bread (about 4 Mio Euros). The contribution rate of Nokia was ~80% according to commit logs; the contribution rate of The Qt Company is at ~40% - and it's mostly on stuff important to them (i.e. which they can sell). So at least 50% are open source contributions by others. This information is all publicly available; you can read it yourself. So the Qt Company massively profited from this and should stop complaining and turning crooked things.
And they have to stop their u-boats, which act anonymously and make opinion.
Here some figures: Nokia bought Trolltech and thus the intellectual property of Qt 4 for around 100 million Euros, and then released it to the public under LGPL. Nokia also payed for the development of Qt 4.4 to 5.0, and then "sold" everything to Digia for a piece of bread (about 4 Mio Euros). The contribution rate of Nokia was ~80% according to commit logs; the contribution rate of The Qt Company is at ~40% - and it's mostly on stuff important to them (i.e. which they can sell). So at least 50% are open source contributions by others. This information is all publicly available; you can read it yourself. So the Qt Company massively profited from this and should stop complaining and turning crooked things.
And they have to stop their u-boats, which act anonymously and make opinion.
Glad to hear that. How about we change the name to QueTee so that we still can everything starting with a Q and people finally pronouncing the name right? :D
I would rather recommend to stay with the name but add a prefix such as "Free Qt" to demonstrate that it is still and will remain a robust Qt branch doing without incompatible changes and focussing on the essentials. I wouldn't even mind to start with 4.8.6, but also 5.6 is OK (the last LGPL 2.1 version). Work should concentrate on stability, compatibility with relevant platforms and finer grained modularity using a standard build system (such as modern cmake). Rewriting everything just to worship the "modern C++ god" is a no-goal from my point of view.
Nope as a QML developer 5.14 is bare minimum because of the many changes like proper 4k scaling support, Splitview, Table support, way better Android build, usable Qt3d and many quality of life improvements.
Are you aware of Dart and Flutter? I also used Qt on Android and iOS once. Won't do it again. A lot of linking, deployment and licensing issues to use something where by the end of the day I have to take care myself that it meets the platform look and feel. QML/Qt Quick was a nice idea when Nokia and others wanted to establish a common mobile platform based on the Qt framework. Today for scripting/mobile UX focussed developers there are much better options.
We're working on a cross platform mobile app rn and we're using QT because "everyone else in the company is using it". It might be good for desktop, but I've found it to be nothing less than frustrating, it reinvents the wheel for mobile, and doesn't do it very well. It's still missing many features, we still have to keep going back to native views to implement things because QT just can't do certain things. We've lost developers because they want to work with mobile technologies and QT seems like 10 steps back. Swift and Kotlin address many issues of cpp, we don't have access to the wide amount of mobile libraries. We replace things with cpp libraries never compiled for ARM that ends up with incredible amounts of code that would take a few lines in native. Every library we add brings more headaches. And then we have desktop developers diving in and designing everything like it's desktop, button and menus too small, scaling the view to fit different device sizes. ugh
Yes I am aware of the alternatives. Still having used a ton of UI libraries (Unity/Unreal/Godot/C#/QtWidgets/Flutter and web development) I would still choose QML by a landslide. My project ScreenPlay [1] (Cross plattform animated wallpaper and desktop widgets) is written 100% in QML and C++. I use the build in Material Design on desktop which works really nice with fancy animations. At work I develop a cross platform Qt app for desktop and Android tablets. With QtCreator 4.11 they unified the apk creation for all arch and arm versions.
[1] https://gitlab.com/kelteseth/ScreenPlay
[1] https://gitlab.com/kelteseth/ScreenPlay
Interesting. How did you solve the LGPL licencing issue? Did you have to pay a commercial licence and pay royalties to The Company?
EDIT: ok I see, your project is AGPL. But that just moves the issues to your clients; how do they solve the issue?
EDIT: ok I see, your project is AGPL. But that just moves the issues to your clients; how do they solve the issue?
When distributing qt on android you can simply write an guide on how to decompile the apk, replace the qt .so and compile it again. I haven't done it yet so I'm not 100% sure about this. Also you could simply install ministro for this. https://doc.qt.io/qtcreator/creator-deploying-android.html
I had so many linking issues because of the Qt so on Android that I finally had to statically compile the run some tests at all, and in consequence to replace Qt with something else to avoid royalties. The problem of "DLL hell" (i.e. symbol conflicts between library versions) is well known on Android.
Arguably, licensing revenue was a drop in the bucket for Nokia and they had a lot more to lose with the liability that came from commercial customers. It was a hard move to (at least partially) undo for the Qt Company.
Switched QtQuick 3D from LGPL to GPL?
Is that the regular license FUD or what? I don't see which 3D module you're talking about.
Is that the regular license FUD or what? I don't see which 3D module you're talking about.
No QtQuick3d [1] was from the beginning GPLv3 only (It is not even released yet, but Qt 5.14 release is tommorow). It is a bit awkward because now there are competing 3d engines inside one toolkit.
[1] https://doc-snapshots.qt.io/qt5-5.14/qtquick3d-index.html
[1] https://doc-snapshots.qt.io/qt5-5.14/qtquick3d-index.html
What I did write was that they switched their licensing default for most new modules from LGPL to GPL. So unlike Qt Quick (the original 2D Qt Quick) which was started under Nokia and licensed LGPL (or commercial)… the new Qt Quick 3D (*) was never licensed under LGPL but is licensed only under GPLv3 (or commercial).
https://github.com/qt/qtquick3d
https://github.com/qt/qtquick3d
Trolltech were pretty awesome, in their days. The “poison-pill BSD” setup is pretty smart; if i remember correctly , it was introduced when they started wobbling a bit from the commercial perspective, in order to keep the community calm while they went looking for buyers (which they eventually found in Nokia). It would be sad if the switch had to be triggered at a time when QT is supposed to be “back in the game” after years of uncertainty.
Dear Qt owners, don’t mess around. If you can’t make money from Qt, it’s not because of the license. Build more bridges, and more developers will come to you.
Dear Qt owners, don’t mess around. If you can’t make money from Qt, it’s not because of the license. Build more bridges, and more developers will come to you.
>If you can’t make money from Qt, it’s not because of the license.
QT stock is up 124% this year, +247,06% last 3 years.
Qt has de facto monopoly in embedded, medical, automotive, appliance and industry automation. It works in Embedded Linux, INTEGRITY, QNX, and VxWorks.
Qt just launched Qt for MCUs (bare metal toolkit for low end microcontrollers). It runs on Cortex-M with several different 2D accelerators. It's yet another market with no serious competitors.
QT stock is up 124% this year, +247,06% last 3 years.
Qt has de facto monopoly in embedded, medical, automotive, appliance and industry automation. It works in Embedded Linux, INTEGRITY, QNX, and VxWorks.
Qt just launched Qt for MCUs (bare metal toolkit for low end microcontrollers). It runs on Cortex-M with several different 2D accelerators. It's yet another market with no serious competitors.
That’s good, so why change the license now? Is it just greed?
Nobody knows what type of change they want. Their paying customers don't care because the product is double licensed.
I suspect it has something to do with some 3d libraries and code they would like to include, but I don't know.
I suspect it has something to do with some 3d libraries and code they would like to include, but I don't know.
They tried and learned that most FOSS don't want to pay for their tools, so they turned their focus to those that actually care to pay and have been doing quite alright.
Numerous frameworks didn’t even bother to turn to FOSS, and maybe they’re also doing alright. We cannot be sure though, cause no one knows their name.
The point of going foss, in my long-distance bystander observation, is to create an essential part of the market: skilled developers. Not to push your sales to everyone’s face, nor to whine that deals are too cheap. Foss folks will never pay, because they are not business for client, they are people for people (who work for business and sometimes make tech decisions based on a weekend experience).
The point of going foss, in my long-distance bystander observation, is to create an essential part of the market: skilled developers. Not to push your sales to everyone’s face, nor to whine that deals are too cheap. Foss folks will never pay, because they are not business for client, they are people for people (who work for business and sometimes make tech decisions based on a weekend experience).
If you want names, OutSystems, Xamarin, VCL, WPF/UWP, Cocoa, UIKit, Telerik, CodenameOne, Gluon,...
That’s lame argument, if it is, and I don’t feel like nitpicking. Almost all of these are either dual-licensed free to use for foss folks or charged very indirectly.
You still cannot be full-commercial and not have sap/oracle-like salesmen squad.
You still cannot be full-commercial and not have sap/oracle-like salesmen squad.
> Background is the wish of The Qt Company to change some of the contract provisions. It is still a bit unclear which ideas exactly they are pursuing
I think this is the reason of the timing of this post.
Because else, this post is just reminding the existing contracts around Qt.
I think this is the reason of the timing of this post.
Because else, this post is just reminding the existing contracts around Qt.
Maybe because Qt6 is on the horizon? Also they changed the license of some Qt modules just 2 months ago: https://www.qt.io/blog/change-in-open-source-licensing-of-qt...
Can you briefly explain (or link an existing explanation) a summary of the changes the Qt Company is asking for, to someone who's interested but not intimately familiar with the details?
It says in the article and the quote that the proposed changes are still unclear.
I understand that. I was hoping someone who's closer to the matter could characterize them in broad strokes even if details were still unclear.
I know nothing more than you do.
It would be good for KDE to get stronger backing, but I've heard RedHat avoids backing KDE and focuses on Gnome, due to aversion¹ to contributor agreements², is that correct in that case?
1. https://opensource.com/article/19/2/cla-problems
2. https://www.qt.io/legal-contribution-agreement-qt
1. https://opensource.com/article/19/2/cla-problems
2. https://www.qt.io/legal-contribution-agreement-qt
At KDE, we don't require signing CLA to contribute, this is a requirement in our manifesto[1]. But contributor can assign their right to the KDE e.V. if they want using a Fiduciary Licensing Agreement[2].
[1]: https://manifesto.kde.org/commitments.html
[2]: https://ev.kde.org/rules/fla.php
[1]: https://manifesto.kde.org/commitments.html
[2]: https://ev.kde.org/rules/fla.php
KDE itself no, but Qt requires one (second link above)?
Ironically, RedHat themselves sometimes make an exception, like the first link mentions:
> We reluctantly sign tolerable upstream project CLAs out of practical necessity.
Ironically, RedHat themselves sometimes make an exception, like the first link mentions:
> We reluctantly sign tolerable upstream project CLAs out of practical necessity.
It all goes back to the early days of Gtk vs KDE, when Qt still had non-GPL compatible license.
Red-Hat is the biggest employer of Gtk/GNOME devs, so...
SuSE and Mandrake were historical the biggest ones that cared about KDE.
Red-Hat is the biggest employer of Gtk/GNOME devs, so...
SuSE and Mandrake were historical the biggest ones that cared about KDE.
I recommend the KDE neon distro to every Linux-curious person I meet. It's the latest and greatest KDE on top of an Ubuntu base, and it's by far the best desktop distro I have tried in my ~20 years of using Linux on the desktop.
A fantastic DE experience indeed.
Just some advice: public consensus is that if you don't want the bleeding edge of KDE, Kubuntu is basically just as good (KDE over Ubuntu) and reportedly is more compatible with various hardware — so if your laptop has issues with Neon, try Kubuntu as a nearly identical alternative.
Note that you can get KDE on any major distro, e.g. Fedora, Arch. I can't recommend it enough, KDE is the dream DE — great out-of-the-box, but settings for pretty much everything, set each once and then forget it as it gets out of your way without sacrificing any feature whatsoever. There are a few minor glitches, but much less so than Gnome or MacOS or Win 10 in my anecdotal experience (notwithstanding display support, that's driver-related and whole other ballgame).
Just some advice: public consensus is that if you don't want the bleeding edge of KDE, Kubuntu is basically just as good (KDE over Ubuntu) and reportedly is more compatible with various hardware — so if your laptop has issues with Neon, try Kubuntu as a nearly identical alternative.
Note that you can get KDE on any major distro, e.g. Fedora, Arch. I can't recommend it enough, KDE is the dream DE — great out-of-the-box, but settings for pretty much everything, set each once and then forget it as it gets out of your way without sacrificing any feature whatsoever. There are a few minor glitches, but much less so than Gnome or MacOS or Win 10 in my anecdotal experience (notwithstanding display support, that's driver-related and whole other ballgame).
Neon is KDE over Ubuntu, with a completely stock KDE packaging rather than the slightly Ubuntu-modified KDE in Kubuntu.
So hardware support really should be identical.
So hardware support really should be identical.
I use KDE in Debian testing for a long time already. Easily the best DE around. Though I wish Debian would get faster updates. Even though testing is supposed to be rolling (besides freezes), something seriously stalls new Plasma uploads there.
Typically, "slower" updates in Debian testing are due to the fact that the new package version has known breakage that makes it unsuitable for release, or requires dependencies to be updated and this in turn breaks existing packages (either the build, or the package itself). These situations have to be managed via a "transitions" mechanism. When in doubt, there is a tracker at https://qa.debian.org/excuses.php that reports on why a newer version of the package has yet to enter the testing channel.
Usually, but it's not the case here. In the case you described, you'll see the new upload in unstable, that didn't get to testing yet. In this case, it's simply not there at all:
https://tracker.debian.org/pkg/plasma-desktop
So I wonder if there is some kind of other blocker.
https://tracker.debian.org/pkg/plasma-desktop
So I wonder if there is some kind of other blocker.
Looks like it's being kept out of unstable until other transitions are complete. E.g. see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919218
Interesting. Hopefully once this is resolved, new Plasma will follow.
And regarding KDE and Qt. I wish Qt already would have Vulkan options instead of OpenGL, and KWin would use it as well.
And regarding KDE and Qt. I wish Qt already would have Vulkan options instead of OpenGL, and KWin would use it as well.
To be pedantic, Neon is not a distro, it's a project made by some KDE contributors (they state so themselves) and FTR is by no means the "official" distribution by KDE.
Disclaimer: I package the KDE software stack for another distribution (openSUSE).
Disclaimer: I package the KDE software stack for another distribution (openSUSE).
KDE neon is downloadable as a LiveCD with an installer, it shows as "neon Linux" in the bootloader, and you use pkcon rather than apt as a package manager.
You could add the repos yourself to Ubuntu and have something very similar, but the way it is distributed, it is absolutely a distro.
It is certainly not the official, canonical KDE distro in any way, it is just a good distro with phenomenal KDE integration.
You could add the repos yourself to Ubuntu and have something very similar, but the way it is distributed, it is absolutely a distro.
It is certainly not the official, canonical KDE distro in any way, it is just a good distro with phenomenal KDE integration.
How well does it integrate with non-Qt apps in terms of look and feel these days? Stuff like LibreOffice and Firefox, but also really any random Gtk app.
Am I the only one that finds it weird that a document like this, that basically shouldn't care about layout, and is very unlikely to be printed by anyone (except maybe the author himself), would be distributed as a .pdf?
positronium(6)
Woah, I had no idea about this. I wonder what kind of new changes would take place if Qt were BSD licensed, such as languages like D embedding it as a solution for UIs as part of the standard library (they already do this for SQLite and Curl).