Qt LTS Releases To Be Restricted To Commercial Customers, Other Commercial Changes

[berolinux]

I'll never understand why Qt had such a success over wxWidgets, which has been always free even for commercial use (permissive license), and supported native widgets far before than Qt. Since the first Qt release, I always considered it a toolkit I need to build because many apps require it, but that I'd never use for writing an app, due to its confusing commercial position and its non-permissive license.

Try writing some code in both. Qt's API is far superior, and a real time saver.

[berolinux]

So, what does this mean for KDE Plama and other open source programs that use Qt ?

Exactly nothing.

We don't need their binaries, distros do a good (typically better -- better integrated with other system libraries) job at providing their own.
We also don't need LTS releases. Nobody in his right mind would still use Qt 5.8, 5.14.1 is much better in every way.

The only possible use for prehistoric (AKA LTS) releases is having some piece of code that needs to undergo certification every time anything changes. That's not what open projects do, that's what big companies do and they can afford shelling out money to keep supporting an ancient release nobody else wants.

The Qt guys are doing the right thing here.

[madscientist159]

Exactly nothing.

We don't need their binaries, distros do a good (typically better -- better integrated with other system libraries) job at providing their own.
We also don't need LTS releases. Nobody in his right mind would still use Qt 5.8, 5.14.1 is much better in every way.

The only possible use for prehistoric (AKA LTS) releases is having some piece of code that needs to undergo certification every time anything changes. That's not what open projects do, that's what big companies do and they can afford shelling out money to keep supporting an ancient release nobody else wants.

The Qt guys are doing the right thing here.

Well said.

Also, this news serves as a good reminder of why the GPL (not the Apache, BSD, etc. licenses) remains absolutely vital to keeping projects open despite changing owners / management. I've heard all the arguments in favor of the BSD style licenses, and I'll be honest that if we're looking to save some time for a project that might be kept internal / proprietary vs. opened up we'll generally look for BSD sources to pull in (and if unavailable, then we'll task internal resources to write our own proprietary code), but at the end of the day I look at it this way: codebases released under BSD style licenses, while more "free", gravitate slowly (i.e. under their own weight) toward a choice of the modern version (but binary-only) or the ancient unmaintained version (but open), whereas codebases released under GPL either stay ancient / unmaintained or as they grow access to the source code remains. Since we rely heavily on having source, not some binary that we need to trust a third party for, on balance we consume far more GPL code (and by extension contribute back fixes for far more GPL code) than anything else at this point.

Note I'm not saying all projects are this way, just that this is the natural tendency, and that it takes a firm hand at the top (or among the key developers) to continually counter the drift that would naturally occur in those directions.

In fact, a curious quirk of the OpenPOWER firmware is that since it is Apache licensed, we tend not to spend a lot of effort trying to upstream anything (despite a hard mandate internally that we make our full firmware code open source) -- when a competitor could just copy the changes from generic "vanilla" upstream and make their platform improvements available in binary only form, why make it easier for them? At least this way they'd have to strip out our platform specific code first. Basic business decisions in the end, but things that people may or may not initially consider when they look at the licenses...

[cesarcafe]

Also, this news serves as a good reminder of why the GPL (not the Apache, BSD, etc. licenses) remains absolutely vital to keeping projects open despite changing owners / management. I've heard all the arguments in favor of the BSD style licenses, and I'll be honest that if we're looking to save some time for a project that might be kept internal / proprietary vs. opened up we'll generally look for BSD sources to pull in (and if unavailable, then we'll task internal resources to write our own proprietary code), but at the end of the day I look at it this way: codebases released under BSD style licenses, while more "free", gravitate slowly (i.e. under their own weight) toward a choice of the modern version (but binary-only) or the ancient unmaintained version (but open), whereas codebases released under GPL either stay ancient / unmaintained or as they grow access to the source code remains. Since we rely heavily on having source, not some binary that we need to trust a third party for, on balance we consume far more GPL code (and by extension contribute back fixes for far more GPL code) than anything else at this point.

I'm afraid it's exactly the opposite: If a GPL project is developed by a business that also exploits the project commercially, like in the case of Qt (by selling commercial licenses to users who want to use the project for commercial applications while forcing the rest to develop only GPL projects if they don't buy a license), then if you invest money in developing commercial applications with that project, you are taking a very high risk: If at some point they cease business, you are left with a commercial license that can be used with an older unmaintained version only, while future developments from the community will be GPL'ed, so you won't be able to use it.

On the other hand, permissive-licenses are very safe no matter if you develop open source or commercial applications. And your rationale about them leading to slow development is not real: I wouldn't say LLVM, CMake, VTK, Python, etc, etc, etc are slow-paced developed projects at all.

[cesarcafe]

Try writing some code in both. Qt's API is far superior, and a real time saver.

My first contact with Qt was with one of the very first versions (in the late 90s if I recall correctly). I never liked that it requires its own tools for parsing custom syntax in some files, because that makes your code depend too much on a custom tool that is not developed by you. Adding that to the non-permissive license, I chose wxWidgets at the time that I needed to decide.

[madscientist159]

On the other hand, permissive-licenses are very safe no matter if you develop open source or commercial applications. And your rationale about them leading to slow development is not real: I wouldn't say LLVM, CMake, VTK, Python, etc, etc, etc are slow-paced developed projects at all.

I would state those projects are very high risk for anyone that needs source code to them. There is absolutely nothing stopping development from moving behind closed doors and source being made available to only select "partners" -- if it's made available at all. We would never authorize development of any software that relied on continued development of those projects as a result, and in fact there is a very serious concern that Clang/LLVM could end up in a situation where you have to either accept vendor (e.g. Intel) optimized, sourceless binaries or take a performance hit / abandon otherwise open software that relies on the now closed-source binaries.

Yes, we've been there. Yes, it's a royal pain, very, very costly, and we'll never do it again. For now we sort of tolerate Clang/LLVM only because GCC remains at effective feature parity.

[ddriver]

This will pretty much have no impact other than making the company look even worse.

They struggle to make money because their product / pricing / business model combo sucks and nobody is lining up to buy it.

So what's their solution? To make their business model even worse and more milking to make up for the issue of it being bad in the first place? I am sure that will work out just fine...


It is true that when it comes to its capabilities and language domain, Qt is second to none, mostly because it pretty much sits in its own category. That makes it subjectively "the best" there is, but that accomplishment isn't all that meaningful without any viable competition.

Qt is not the worst framework to work with out there, but it is too stiff and bloated for what it offers, which has a number of negative impacts to the people, whose livelihood depends on it. And it hasn't been getting any better, in fact, the framework suffered quite a lot of damage and work hours lost due to wandering about, trying to figure out different things to cater itself to people with. Due to this, the benefits of performance and portability where Qt out-competes its closest rivals is greatly diminished by the limitations and issues of Qt, making it less of an attractive prospect.

It would seem like the best thing for Qt at the moment is for the company to go out of business and transfer ownership of Qt to the projects that make the most active use of it and have no option but continue using it. As for the company employed that actually server a purpose - the actual developers - those can be transferred to the projects that take over. No need to leave good developers unemployed, all the framework really needs to get rid of is the bad management.

I dare say that GLP Qt usage in FOS projects has far greater relevance and economic impact than the company's entire "brave new direction" with their embedded / automotive spin on the framework currently has or is likely to achieve, the GLP "free" version of Qt is making far more money than the commercial version.

[DanL]

What happened to this?

"These changes will not have any effect on existing commercial licensing or services agreements." The situation for KDE may not be as bleak as the 144Hz's of the world would like us to believe.

[cesarcafe]

I would state those projects are very high risk for anyone that needs source code to them. There is absolutely nothing stopping development from moving behind closed doors and source being made available to only select "partners" -- if it's made available at all. We would never authorize development of any software that relied on continued development of those projects as a result, and in fact there is a very serious concern that Clang/LLVM could end up in a situation where you have to either accept vendor (e.g. Intel) optimized, sourceless binaries or take a performance hit / abandon otherwise open software that relies on the now closed-source binaries.

Yes, we've been there. Yes, it's a royal pain, very, very costly, and we'll never do it again. For now we sort of tolerate Clang/LLVM only because GCC remains at effective feature parity.

I really don't understand your rationale. I suppose you don't develop projects that need to be free from copyleft obligations. I always need to classify the third-party code that I use by license (yes, in directories grouped by license), in order to know in what places my work is affected by copyleft obligations and in what places it's free from them, and making sure I can deliver binaries not affected by copyleft if I ever need to do that.

Also, I don't understand what's the cost/pain of a non-copyleft project being developed as closed source by anybody. The code that was available permissively licensed continues to be available, so you can use it, and the community can continue developing it as well. The other side (copyleft code with commercial licensing available) is really unsafe and risky because the community cannot continue the development in a copyleft-free license (unless you don't need to be free from copyleft obligations, as I said).

[madscientist159]

I really don't understand your rationale. I suppose you don't develop projects that need to be free from copyleft obligations. I always need to classify the third-party code that I use by license (yes, in directories grouped by license), in order to know in what places my work is affected by copyleft obligations and in what places it's free from them, and making sure I can deliver binaries not affected by copyleft if I ever need to do that.

Also, I don't understand what's the cost/pain of a non-copyleft project being developed as closed source by anybody. The code that was available permissively licensed continues to be available, so you can use it, and the community can continue developing it as well. The other side (copyleft code with commercial licensing available) is really unsafe and risky because the community cannot continue the development in a copyleft-free license (unless you don't need to be free from copyleft obligations, as I said).

Without going too far into the exact details of what happened to us (it's a bit esoteric, but was very instructive), your rationale only holds if you (or your organization) is prepared to fully maintain the software as of the last fork in perpetuity. That means security patches, new features, performance improvements, etc. or you fall behind the competition and the cost of staying on the dying fork outweighs the cost of a ground up rewrite of whatever you were building that relied on it.

The simplest likely scenario with a key tool like Clang/LLVM (and the main concern) is:

• Large project Z is built on project X that has a BSD-like license. Project Z may be open or closed source, the distinction is irrelevant in this case (with compilers or LGPL libraries in Project X's place, it's irrelevant as well)
• Because you have full source code, you either modify X slightly or perhaps build it for an unusual system (non-x86 ISA, non-Windows environment, whatever -- point is something that isn't the usual use case for project X)
• You invest man-centuries of effort into project Z -- enough developer time and money that your organization might go out of business if you had to do a rewrite from the ground up. Project X similarly grows.
• Project X is taken over by a competitor, or simply one of those companies that thinks their innovation needs to be kept secret, that binaries are sufficient for everyone. Accidentally, or on purpose, your target platform(s) are excluded from those binary compilations.
• The remaining non-corporate developers are woefully inadequate to replace the sheer effort put in continually by the new ownership, so any attempt to fork the codebase for additional development or even maintenance fails. Most developers familiar with the product are already on the payroll of the new ownership, so forbidden from touching the old open version.

Now what? You've got a copy of code that's growing obsolete by the day. It might have security flaws that are now being patched only in the binary versions, it might just be that your competitors have access to better tools -- if they are willing, of course, to use a binary-only, effectively proprietary program.

There is no good answer at this point. You're basically stuck.

If we peer a little further into the future, past your organization's fire sale or ignoble death, one sees that over time, even just keeping the source of project X proprietary is not enough. EULAs start to appear demanding licensing, audits, data access and other concessions to keep using the binary tools. The cost of a ground-up rewrite of the critical tool by now is so high that various non-profit and educational organizations and individuals start to band together, writing code under a new license called the NGPL....and history repeats.

EDIT: Meant to add this in originally, but forgot:

To be fair, you have a point on commercial licensing of the GPL source. That being said, how is that any different than the risk taken with any other proprietary, licensed software package? When you're outside of any of the OSS-recognized open source licenses, and you don't own the copyrights (the actual legal full ownership of the code, not just a license to use it, regardless of how it's marketed) you're stuck. Worse you may not even have the right to modify the code or to use it in certain situations. I am aware of several cases including one very prominent one that ended up being very public (though the actual cause was never publicized, only the product discontinuance and replacement with an inferior "new' version was) where a key proprietary software component was being provided by a company that went under. Because copyright on the key part was not owned by the downstream company, and they had no rights to change it or develop it, the higher level product was stuck at a specific level and abandoned. I don't see how the situation with Qt is any different, aside from the fact that large parts of it are actually LGPL so there's a decent chance you could keep the core and rewrite only a small amount of library code. Contrast that with the fully proprietary vendor going under -- the latter is much worse. I've seen the fallout, it isn't pretty.

To frame the argument slightly differently, why should I provide you with free updates and improvements to a codebase you use, just because a third party you relied on went bust, and especially since you are profiting from that work but don't think you need to pay me anything? Just because I work on open source doesn't mean I like to work for free; I may make an exception if you share your subsequent development with me (basically a kind of quid pro quo), a.k.a. the GPL, but the alternative was for no one to maintain that library. Also so far as I know you're still perfectly free to hire your own developers to enhance the codebase you licensed; if you didn't get at least that right then you didn't negotiate a very good contract when you licensed the software in the first place!

If anything, all I'm hearing is that if copyrights on software are routinely outlasting the companies that created them, copyright duration might be a bit too long right now.