LGPL has long been a thorn in the side of Qt Company management. Nokia had bought Qt for $150 million, developed and popularized the platform, and then released everything under LGPL. Digia/The Company then bought the intellectual property from Nokia for just 4 million Euros and have been trying to make money from it ever since. Now, with Corona, the management seems to have had a good opportunity to get rid of its annoying obligations to the open source community.
Just to add a little: there's some concern, including among commercial users (including yours truly), that this is a Very Bad Idea (TM).
Thing is, non-commercial and free software projects (KDE is one of the biggest ones, but not just KDE) have a significant contribution, quality-wise, to Qt. Most commercial users are on LTS releases. They rarely report bugs in current versions. With some exceptions (e.g. Wayland), they rarely test new features as they become available. They rarely put too much effort into bug reports for LTS releases, too. That's just how commercial development works. Unless it's a critical bug and you have no choice, your employer won't pay you (or you can't charge your customer) to help another company fix their code.
Qt has a large foothold in FOSS and non-commercial software, and that provides a great deal of real-world exposure to a codebase that's old enough, and complex enough, that real-world exposure is crucial. IMHO, if they lose this, Qt will stop being a useful choice for any kind of development, cross-platform or not, within a few years.
(Edit: to be clear, it's not just that the FOSS community basically provides free beta testing -- even if technically it sort of does. This is an artifact of the way FOSS, and many Linux distributions, too, work today -- e.g. most distros don't ship the LTS version, they ship the latest version, simply because it's easier to fit that into their release schedule. Whether good or bad, it means that a big chunk of Qt app users are on the latest stable version, not on LTS.)
That's all in addition to all the third-party contributions, which are a small, but not insignificant portion of the Qt code.
I have written a fair amount of software in Qt. It has been clear to me from the actions of the Qt company (via the amount they charge for it, getting rid of indie plans which allowed you to use it Qt for ~350 bucks a year vs the $5508 a year that they have chosen the strategy of milking the captive users that Qt has rather than expanding Qt out and courting new users. For better or for worse at this point I see closed source Qt going the way of Delphi. Qts long term survival depends on a viable and vibrant OSS fork.
I don't have a lot of experience with it, but Copperspice looks promising, and doesn't need the MOC. Does anyone else have experience with any critical differences between Qt and Copperspice?
i.e. you do not need a license to have commercial qt programs, as long as you correctly use LPGL as a license, which is really really simple.
IANAL but their licensing pages and legal pages are extremly misleading.
If The Qt Company discontinued the FOSS
version of Qt, the Qt framework would become available under the BSD license, and there would no longer be a contributor licence agreement allowing a company to sell the work of another company.
> in addition to all the third-party contributions, which are a small, but not insignificant portion of the Qt code.
In the last years more than 50% were open source contributions. At Nokia times they were only 10 to 20%.
If The Qt Company discontinued the FOSS version of Qt, the Qt framework would become available under the BSD license, and there would no longer be a contributor licence agreement allowing a company to sell the work of another company.
But the rumors were that the Qt Company planned to do the minimum necessary to satisfy KDE Free Qt Foundation agreement, namely to release the source 12 months after release of the proprietary version. So, then Qt would not become available under the BSD license.
I'm sure you'll have a couple of shysters in tow trying to turn it this way. But at the end of the day (i.e. in court) only the effective will of the parties counts, no matter what (possibly wrong) wording was used in the contract. Unfortunately, KDE is not expected to go to court. The Company will take advantage of this.
I read the linked email and now I'm even more confused about TFA.
Linked email from KDE:
> But last week, the company suddenly informed both the KDE e.V. board and the
KDE Free QT Foundation that the economic outlook caused by the Corona virus
puts more pressure on them to increase short-term revenue. As a result, they
are thinking about restricting ALL Qt releases to paid license holders for the
first 12 months. They are aware that this would mean the end of contributions
via Open Governance in practice.
TFA (the entirety):
> There have been discussions on various internet forums about the future of Qt open source in the last two days. The contents do not reflect the views or plans of The Qt Company.
> The Qt Company is proud to be committed to its customers, open source, and the Qt governance model.
So, are they claiming that they never planned to "restrict ALL Qt releases to paid license holders for the first 12 months", or are they saying this plan still counts as "committed to open source"?
>> The Qt Company is proud to be committed to its customers, open source, and the Qt governance model.
Bull.
From January (eg ~2.5 months ago) they've stopped people being able to download the Open Source Windows, macOS, and Linux versions of Qt without first signing up for a "Qt Account".
eg you're now required to be tracked / able to be spammed / (etc) for even the OSS version of Qt.
That's not how companies "committed to Open Source" do things. :(
The crap they're reported as wanting to do now, is right in line with their demonstrated anti-OSS direction.
Not sure about online installers and not keen to find out, but I just built a Qt app last month and used the offline Windows installer for 5.14 from qt.io as part of the Windows build environment setup, and I’m sure I don’t have a Qt account (yeah checked in my password manager), so saying the open source Qt builds can’t be installed without an account is not accurate.
They can only do that for the packages they build themselves, which are mainly useful to enterprise customers.
Qt being under LGPL, there is nothing that prevents anyone else from redistributing open-source builds of Qt - Debian / Ubuntu through apt, MSYS2 (pacman -S mingw-w64-qt5-whatever), homebrew (brew install qt), conan (conan install qt/5.14.0@bincrafters/stable), vcpkg (vcpkg install qt5)...
Sure. But 99% of people use those packages. Not sure why you say they're only useful for enterprise customers, as they're literally the reference packages. :)
On Linux/BSD though, obviously most people use the in-built package managers where the Qt version is recent enough for their purposes.
That's weird. That launcher version you have is version 2.0.5-2. They retired the 2.x series a while back, and it's up to version 3.2.x now which will not work without a Qt account. :(
Oh it looks like you obtained that launcher from the old "archives" directory?
At least, after disconnecting the internet connection then ignoring the subsequent error (ironic for an "offline" installer!), it doesn't require a Qt account.
For now we (sqlitebrowser.org) will keep with the easy approach of using the official Qt installers.
If Qt does something even further dumb though, we'll likely move to compiling Qt ourselves. And probably then make installers (.msi/.dmg) for anyone else that wants it too. ;)
Would it even increase their short-term revenue? Users who use the FOSS licence will just wait for the next release, won't they? Unless it's urgent that they use the latest Qt, why would they pay up?
Beats me, I'm certainly not dying to upgrade to Qt6. Now, it will be a nuisance if they withhold security patches for a year, though, so maybe that's what they're counting on? Holding security patches ransom?
Nokia’s acquisition was a boost but nowhere near “developed and popularized the platform” - I would bet good money that the amount of licensed customers didn’t change that significantly, under Nokia, outside of the mobile world they tried (and failed) to push it into. In fact, the most significant advancements happened before and after the Nokia period, if i remember correctly. Nokia concentrated on porting it to its doomed OSes and building a cloud infrastructure nobody really wanted to use.
The real value of Qt is not $4m, Trolltech made a decent living out of it. The world has changed a bit since then, but I’m sure there is still plenty of space for Qt in the market.
I think they likely invested a lot to the modern UI stuff, like QtQuick. They also financed the initial PySide project to get LGPL licensed Python bindings for Qt (PyQt is GPL/commercial license only).
But indeed, in other areas such as non-Nokia mobile platforms they even blocked progress. It was only after Nokia let go that the Android port really took off and was mainlined for example.
Nokia was not interested in license revenues but in popularizing the platform, especially their open source OS based on Qt. That's why they spent that much money to buy Qt ($150 mio) and then released it under LGPL. And there will always be people who find a hair in the gold pile. That's just the way the world is. Fortunately, most people appreciate what they're given.
They were only interested in the platform inasmuch as it could give them a way out of the hole they had dug for themselves with Symbian. They threw out half-assed implementations of this and that and then abandoned them at the speed of light, because the only real focus was migrating their historical Symbian devs to something that could resemble XXI century tech. I know because I was mulling some projects in the space at the time - I even went to a usergroup event that was supposed to be about Qt and got sold what was clearly a "Qt for Symbian" slide deck.
Trolltech was skimpier but was much more interested in the success of the platform per-se. In many ways the post-Nokia experiences are an attempt at re-discovering the space Trolltech lived into.
> their open source OS based on Qt.
There was never such a thing. They had a Symbian OS skinned with Qt, and a number of Linux incarnations that started with GTK and were later reskinned with Qt. It didn't help that they stroke a high-level agreement to basically adopt Intel's Linux efforts, which were targeting GTK. By the end of these travails, they ended up with something fairly decent but that was just a lame-duck. Nothing was ever "based on Qt" at a fundamental level.
I was a MeeGo user and hobby developer, you don't have to remind me. And you should know that, as I described, it was born with GTK on top (Maemo); when it was rebranded MeeGo it was because they merged it with Intel's Moblin, another GTK-targeting effort, so the innards were very much geared towards GTK to start with.
Software development business is among the least affected by Corona. But Corona is a good opportunity for many managers to use it to justify previous misconduct.
Big customers of QT are Car Companies. And they are affected a lot. However, it is very early to see this impact in a second or third layer company like QT. On the other side, it could be good management (thinking forward).
But I agree with you. They are most likely executing now an old plan under Corona cover.
What The Company can or can't from this contract is not granted unless you have supreme court judgments for the points in question. Otherwise the current patent system, which is primarily based on bluff and blackmail, would not work. As long as there are companies that would rather settle than defend themselves in court, The Company will find a way to stay in the game.
Firstly, you are confusing patent system and copyright in your answer.
Secondly, nt's not about legality of open source license at all.
LGPL or GPL does not burden Qt Company with license obligations since it owns the source code. There is another contract between KDE foundation and QT company that we are talking here.
There's a crisis at the moment, more general, and the crisis has caused catastrophic loss of income at many companies.
Some people say that qt.io is one of the companies in trouble, and that it's reacting by releasing new versions of qt to customers first, and to opensource users a year later.
I've no idea how much income qt.io actually has lost.
The Qt Company (QTCOM). They're publicly traded, so they have to publish yearly financial statements.
Their employee count has also doubled, which is why they're not making any profits despite the revenue growth.
Edit: Ah, you're pointing out that only 25% of their revenue is commercial licenses, while most of their revenue is consulting. I don't know if that's really such a big deal.
If you know enough about their business model to state that it doesn't work, then you know the answer to that question. So why do you ask, what are you trying to say?
I think Qt needs to rethink their licensing model.
Currently you either pay them a LOT of money for everything they offer, or you don't pay them anything and just use the LGPL version (when that's possible).
It seems their current strategy is to milk the users that can't use the LGPL users as much as possible,
Additionally they try to convince as many people as possible that the LGPL version won't work for them, by having very confusing licensing terms on their website.
My company currently uses the LGPL version of Qt, and would gladly pay for the commercial one. In the Trolltech and Nokia days they actually did pay for it, but the prices are no longer affordable us.
So we are stuck with the LGPL version for now.
We don't need a trillion supported platforms and tons of features. We have a Desktop App that runs on Windows (and in the future maybe Linux), and we use the old Widget stuff (currently no QML).
We would gladly pay for the features we need, but not the ridicolous amound they are charging now.
> My company currently uses the LGPL version of Qt, and would gladly pay for the commercial one. In the Trolltech and Nokia days they actually did pay for it, but the prices are no longer affordable us. So we are stuck with the LGPL version for now.
Huh, price isn't even a THAT big problem. Software developed with LGPL version can't use the commercial one.
> 2.13. If I have started development of a project using the open source version (LGPL), can I later purchase a commercial version of Qt and move my code under that license?
> This is not permitted without written consent from The Qt Company. If you have already started the development with an open-source version of Qt, please contact The Qt Company to resolve the issue. If you are unsure of which license or version to use when you start development, we recommend you contact The Qt Company to advise you on the best choice based on your development needs.
There is no legal barrier for them to relicense Qt from LGPL to a commercial license for a customer. They are just strongarming customers into paying for licenses early on during development by refusing to do so.
My company accidently used one of their GPL-only products (on screen keyboad), thinking it was LGPL. We did the right thing and reached out to them to pay for it after it was already deployed to customers.
We had to pay for the entire Qt platform. 20,000 dollars plus a per-device royalty. That was a big mistake on our part, not paying attention to the licensing.
Agreed completely. I think the licensing model is the issue, and if you look on this page alone people who have had to pay all say it was because of a mistake rather than as something they did because the money gave their company an advantage.
Also, I've personally tried out Qt a few different companies over the years and several of them would have been fine paying $50-200/dev/year (depending on company size), but the current price starts at $5508/dev/year! This is so much higher than Jetbrains or Visual Studio pricing that it's clearly targeting a market other than normal developers. This creates an awkwardness for Qt in my opinion. They want to build a community of developers to encourage and grow use of Qt, but most developers in the community are priced out from participating outside of open source.
What’s wrong with the LGPL? If you dynamically link them, then you don’t need to open source your product. It’s only a problem if you want to statically link.
Nothing is wrong with the LPGL version for us. Static linking would be nice sometimes, but really necessary.
My point is that my company would be willing to pay for Qt (and it did pay in the past), but not that much. In the current situation they don't get any money from us at all.
I'd love to know more about opinions of fellow commenters, just a "what-if" question:
If tomorrow you had some big project such as Qt in your hands, and had 100% freedom to choose how to proceed with it (in matters such as what license to apply, what sustainability model to seek, etc.) what would you do?
I always feel that pure GPL is the best but only idealistic way to go, because working for free is not compatible with paying your bills. Then LGPL, and maybe other licenses such as Apache, are nice but at the end of the day allow that private companies with private pockets benefit from the project without helping it at all (either with work or with cash), which I know is one side of the "freedom" that those open-source licenses bring, but it's one side that I personally don't really like (I'm more of a pragmatist than an idealist). For that reason I feel like dual GPL+Commercial might be the best of both worlds. It would allow basing a company around it, and paying other devs to feed their families, and at the same time users of the GPL variant would themselves be benefiting from and contributing to open-source.
One challenge specific to Qt is that their market is completely different than it was when KDE adopted Qt way back in the late 90s. I ran prerelease KDE briefly in that era and it was incredible for what it was. The other cross-platform options were things like Java Swing and Tk. They were ugly and had funky UI behavior.
Even then, the total addressable market was pretty small, but at least it was anyone who wanted to make a cross-platform app.
Now, most people who want to do that use Electron, React Native, or make a browser extension (or, of course, a Web site). The market is smaller: cross-platform makers who are absolutely committed to Qt or for whom it’s a uniquely good fit (like because they’re using C++).
Think of it like a pharma company with a drug that only treats a rare disease. The TAM is tiny. Unless someone discovers that it also treats some other disease, there’s not a lot they can do to expand the customer base. If they want to make more money or want more short-term revenue (usually at the expense of long-term revenue), charging existing customers more may actually be the best option for them.
When I wrote my first Qt-based code, it still was Trolltech. C++ seemed the obvious choice for a performant application.
But now, I think that C++ is more of a drawback than an advantage for the Qt project. C++ today seems a good fit for high-performance, very niche tools such as trading, games, machine learning libraries, and such, but not for "simpler" software such as the UI of an application. Also finding good competent C++ devs seems to be much harder now. I myself feel like having to go "back" to writing C++ is a bummer, having worked with other more modern technologies.
Bindings to other languages have always been a second-class citizen. The Python one is very nice, though, but that's all. I believe it comes, again, as a difficulty introduced by the language itself.
I feel like Python bindings came along kicking and screaming by the Qt owners. PyQt was originally developed and licensed independently. Nokia was negotiating a relicensing with Riverbank Software. When that broke down and they wrote PySide--basically a reimplementation. That was kind of abandoned with Python 3 and Qt5 until the VFX industry made a big push for PySide2 (rebranded Qt for Python).
Even with all of that, you generally end up reading the C++ docs, it isn't particularly Pythonic, and there are weird gotchas. I can't really fault them for it because you're bound to get that with bindings to another language and it is much better than other UI toolkits.
If your only goal is to pay devs fairly and do the best for the project, the best way for a library is MIT (for an app, GPL) and having a Foundation that companies support with money and development efforts. Examples: Linux, Blender.
If you want to make actual profits, then it is the same license choice but with a company that sells valuable long-term support, development and perhaps proprietary extra features. Examples: RedHat, Canonical, GitLab.
GPL+Commercial requires copyright assignment, which is a pretty sure way to turn off potential contributors. I mean, if you don't want to contribute to BSD-style licensed projects because you don't want others to leech without giving anything back, how on earth could you simultaneously be ok with assigning your copyright to some (sleezy/evil/you name it) corporation?
And no, I don't really have an answer either. Successful open source business models are few and far between. Redhat is perhaps the one big example of a (very) successful open source company.
To some extent I think the worry about leeching is something which can be addressed with culture as well as licenses. Plenty of successful BSD/apache licensed projects around, including with largely corporate contributors, because they understand the long-term value from contributing to the common pool rather than forking and trying to sell "proprietary enhanced" versions.
Assuming the project is a library or a tool that people will need to somehow embed in their program I wouldn't go with GPL. It has some restrictions that are for various reasons hard to accept for a large amount of clients. People try arguing that "you could do this or that to accommodate" but the fact is that many for-profit corporations, even those working with open projects, will have a no-GPL policy. Also with the current trend for web services and what not GPL can be worked around, hence the AGPL.
I'd probably go with LGPL and commercial plugins that enhance the functionality. But this depends on the product having some features that could be mainly useful for companies but not really for individuals.
To some extent LGPL and other "weak" copyleft licenses like MPL or EPL are in an awkward middle-way spot in that they have disadvantages of both full copyleft and liberal licenses, but not that much upside.
Either go full GPL, or even AGPL, or then use a liberal license like Apache-2, IMHO.
I really like Qt for desktop development, use it everyday, but this post makes me feel uneasy.
What "discussions on various internet forums" do they mean? there's been plenty. And, which ones "do not reflect the views or plans of The Qt Company"?
Yeah. I can't imagine KDE using Qt if there's a 12 month turnaround (and they don't have final word of what goes into a release). I would think they'd have to fork and hopefully merge on release.
"discussions on various internet forums" here probably means the KDE forums/mailing list.
From the mailing list
"During the past two years, there have been negotiations between The Qt Company
and the KDE Free Qt Foundation for updating the contract.". More info: https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...
There are talks in the mailing list about forking QT but KDE doesn't seems to want that currently due to lack of developers for maintaining a fork
A lot of developers are experimenting with languages and libraries outside their normal work requirements given the current uncertainties of the future. If you are considering learning QT and come across this bad PR you will most likely avoid the technology altogether. I was looking for a popular GUI framework to build front ends for my rust apps all the controversy around QT made me double my efforts to find a native alternative. I’m still experimenting but I know for sure that I won’t be using QT now.
Same thing happened with Oracle and Java, they lost a lot of potential new developers with their hardline approach to open source.
I think Qt is an amazing product. I would use it for all desktop development if I could. The commercial license is a bit expensive to justify. I think they could do a lot better if the costs were more inline with a Visual Studio license. Right now it is hard to justify it over Visual Studio when I can buy a perpetual license or a yearly subscription for a reasonable amount of money.
I really want to use Qt for a project but between the absurd commercial cost and them playing games with licensing i'm going with either wxWidgets or Lazarus.
Does anyone here use Copperspice? Saw it mentioned elsewhere as a possible alternative. Theyre a kind of fork of Qt5, ditched the moc, and seem to be ran as a regular Floss project. I have no experience with it, but I do with Qt, which I like very much, so if there are users of Copperspice here I'd be very interested in your experience.
Copperspice was interesting as a technical experiment to see if improvements to C++ have made the moc no longer needed. The basic problem with using it to actually write applications is that the development effort on it isn't put into things which make your application better. Modernizing and cleaning up the Qt codebase is great for the people working on Qt (or Cs), but most of the changes aren't actually valuable for users of it.
As long as you don't need LTS support. Im done with commercial development tools. I'd rather endure issues with an open source project that I cant help fix/improve.
Because QT can always move the goalposts. Like only offering LTS support for licensees. I'm already paying enough cash to another VC Vulture (Embarcadero) for Delphi. I've been looking to move my pascal code over to lazarus
No, at that time Qt was not free software. Now Qt is free software and you can fork it and do whatever you want.
The issue seems to be that there are many people that use Qt for free including companies but they won't pay with money or contributions, so if a work will happen except KDE there will be few contributors. Qt includes a version of Webkit that is used in some application, so you need someone to keep on top of webkit security issues and backport the fixes.
> many people that use Qt for free including companies but they won't pay with money or contributions
That is one of the things that free software allows, yeah.
> so if a work will happen except KDE there will be few contributors
Even if that's true, is KDE not enough?
> Qt includes a version of Webkit that is used in some application, so you need someone to keep on top of webkit security issues and backport the fixes.
I assumed that the QT end of that was a thin wrapper around upstream webkit; is it really that involved?
While the core product is LGPLv3+Commercial, most of their extensions are GPLv3+Commercial which makes them not suitable for a lot of apps.
Hence I find it's a bit confusing to say "to be committed to open source" where in practice the only way to use their extension is either to release your apps code (given you distribute the app) or pay for commercial license. IMHO "to be committed to free software" would represent extensions situation a bit better.
> GPLv3+Commercial which makes them not suitable for a lot of apps.
In other words, the license is not suitable for users who are not committed to open source themselves but are not willing to pay either.
Dual licensing with GPL is IMHO the best and often only viable method from the business point of view for small and medium sized companies who sell product and not just service.
QT Company has large customers that are much bigger than it is. Many of them in software business. Turning into yet another software as a service producer for Autodesk or car manufacturers is not in their interests.
> While the core product is LGPLv3+Commercial, most of their extensions are GPLv3+Commercial which makes them not suitable for a lot of apps.
this is FUD - the immense majority of Qt is under LGPL. You can build literally entire OSes out of the LGPL parts.
The only strictly GPL parts are (from this page https://doc.qt.io/qt-5/qtmodules.html) :
- Qt Charts
- Qt Data Visualization
- Qt Network Authorization
- Qt Virtual Keyboard
- Qt for WebAssembly
- Qt Quick WebGL
All the widgets, qt quick, etc... stuff is available under LGPL.
Yeah, can't find another cross-platform UI library with Qt's selection of (permissive license-compatible) widgets. Other UI libraries tend to look like crap (at least on macOS), too.
> most of their extensions are GPLv3 [...] in practice the only way to use their extension is either to release your apps code
Which is exactly what improves and helps grow the open-source world?
GPL makes a product's code, and by infection/extension, other people's code, to be all released under a GPL license. GPL guarantees that users of open-source code won't act as leeches and will themselves contribute more open-source code. Isn't the act of choosing that license, in itself, "a huge commitment" to open-source?
Then they say: OK, seems you want to keep your code private, in order to preserve your IP and leverage over other competitors, and protect your lucrative interests... well that's fine too! You don't want our open-source license forcing you to contribute your code? Fine, we'll waive that requirement. Just pay up.
I think most developers get along pretty well with only the parts available under LGPL; that's not the issue. It's more of an issue that the The Company only represents a fraction of the commit log but even though sells commercial licences of work done by other companies. I'm sure more companies would contribute to Qt if there wasn't this dual licence nuisance and they weren't forec to sign a contributor licence agreement which puts The Company in charge of their work.
Ok, a bit more than last year. One should also analyze what parts were commited. There is a significant difference in the commits by company to the core framework and the new 3D tools and other parts that The Company wants to make money with.
You won't get any support of the "big money" unless the library is at least LGPL so it can be used in closed source applications. GPL is primarily for the idealists, not for business.
Just look at other essetial, widely used frameworks like OpenCV, Skia, Chromium, LibreOffice, just to name a few. In each such open source project a couple of companies are involved who can affort to dedicate a couple of developers to work on the open source frameworks they're using but which are not their income. This is a "coopetition" among companies and everyone benefits from it. In the case of Qt it's restricted because The Company sells licences of work which was done by others (companies and private people) for free.
> In the case of Qt it's restricted because The Company sells licences of work done by others for free
No, using the LGPL code done by third party is still free of charge.
> This is a "coopetition" among companies and everyone benefits from it.
And we also have seen many times developers who released their code as MIT never seeing a dime from these big companies (such as Corejs developer).
LGPL is the way to go to ensure that big corps who make money out of an open source project do pay up. You don't want to release your source code? Then pay for a commercial license, end of story.
> You won't get any support of the "big money" unless the library is at least LGPL so it can be used in closed source applications. GPL is primarily for the idealists, not for business.
Right, of course; hence the failure of Linux and the dominance of the BSD family. /s
I wouldn't say that game consoles use FreeBSD so much as that they use chunks of code from BSD; I mean, the Switch is apparently using a microkernel, so I doubt that it's all that close.
But yes, using permissively-licensed components absolutely is* a good thing, including for the users, who get higher-quality software with less dev time and lower cost of development. Obviously I'd prefer that it was all GPLv3, but given that the alternative in practice is probably fully-proprietary software from scratch, I think BSD is better than nothing.
Using the product while making a closed source application and contributing nothing (money or patches) back can hardly be construed as promoting open source. The "big money" that won't play ball is why they instead have the commercial licensing options.
Nobody claims that. The problem today is that The Company only contributes a fraction to the maintenance and sells licences which includes work done by others. That's a pain point, isn't it?
I don't believe that is the real pain point. The Company could resolve it easily by paying contributors in exchange for signing the CLA. What is more likely is that they can't afford to do this.
That would be much too complicated. Just imagine such a model with OpenCV or some of the other big C++ frameworks. Selling framework licenses is just an outdated business model. It would make more sense to release the Qt framework under BSD and make money with add-on services (as other companies actually do successfully).
It doesn't seem that things being "much too complicated" is the issue when maintaining separate proprietary and open source forks is on the table. Although it's unclear if it actually is or not.
OpenCV (and many other open source frameworks) never had a CLA so this wouldn't be an issue for that. In my opinion there is nothing inherently wrong with dual-licensing but it's expensive and many companies do not have the resources to pull it off correctly. Re-releasing under the BSD license appears to be the backup plan if the Qt Company ever goes belly-up.
> In my opinion there is nothing inherently wrong with dual-licensing
It significantly hampers cooperation. No company in its right mind would make a large investment for free in the development of software sold by another company. Without this unspeakable dual license, a balance is possible, i.e. the companies can invest and use without taking inadequat advantage of each other.
It doesn't have to be "for free". There is a simple solution I already mentioned, which is for the maintaining company to pay in exchange for getting the CLA signed. Serious long-term contributors should have this negotiation before making any large investment. Businesses can ask for royalties up to a cap, individual contributors are likely to get a salaried offer made up-front.
In the event of total failure of Qt's business model and reversion to a BSD license it is also very likely that there will not be much left of a market for big enterprise services around this type of product, so be careful with that double-edged sword. You might just end up with more fragmentation and internal proprietary forks to contend with. On the other hand, independent consulting will always remain an option as it is now.
Considering the quality and capabilities of Qt, I really think they should just sell commercial licences. Considering the fact that the engineers at Qt need to pay to eat and pay their bills just like me, I find it absurd to expect something like this for free. In that sense, I think the current situation is very gracious.
It's not gracious. They have binding contract with KDE to release the code as open source within 12 months.
They can't change that without negotiating new contract. That would require giving something to get something in return. Only thing they can do is to do just the minimum. This is the current issue. They are moving towards the bare minimum.
What about all the people not working at Qt Company that wrote most of the code? Qt company immensely benefits from the work done by others under the condition it remains also available under open source licenses.
This is a good point but I'm not going to be too quick to comment on those developers. Because they may be working on paid products and they contribute to the upstream project when they find certain features missing.
I like opensource, I myself am a Linux user. I just like a world where perhaps individual devs can build nifty useful software that we pay a small fee for and use. This way the small guys can benefit. Unfortunately, the current state of OSS (which has changes since the early days) are concentrating more power in the hands of a few organizations.
Take Sublime Text for example. I like it that an engineer builds something useful, ask a one time fee for it and we pay something really affordable for it (while there was also a free version available). This way, talented software engineers could actually make a decent living without everyone has to build crappy software for an advert-based economy. So, IMHO, opensourcing the software is an act of grace and would be at the discretion of those engineers. To expect everything to be FOSS or perhaps even demand that, I find is detrimental for individual software engineers/small players.
Many contributors aren't. And even if they are, there is a clear open license they rely on, and Qt company is in the unique position to be allowed to sell exceptions to that. Companies actually contributing to open-source they use is a good thing.
Qt Company is also a 300+ employee company with 8-digit revenue. They are not some small shop trying to survive, they are a corporation that over-promised growth to their shareholders and now is trying to squeeze rules that have existed for 20 years to turn some part of the open-source ecosystem into paying customers, threatening to risk the entire open ecosystem around it for this, which includes many small shops and individuals.
One problem is reluctance to buy closed-source from a one man business, it could even be regarded as negligent. Actually, having said that, Delphi had a thriving third party component ecosystem where developers commonly purchased the source code for an additional fee.
I fully agree it would be great for Qt as a company to have a great business model. That being said, it's not that obvious if making Qt as a product commercial-only would be effective, as there are other options on a market that don't cost anything (or much). Maybe Qt should pivot into services instead?
Edit: This article gives a bit more context. https://www.phoronix.com/scan.php?page=news_item&px=Qt-Open-...