Qt licensing policy madness

[sinbad]

I'm going to ping my Qt contacts about this, because it sounds really odd.

[sinbad]

Here's my email:

Some of our users have been discussing Qt licensing recently and they've hit upon a fairly serious problem. Obviously the switch to the LGPL is a good thing for them, but as they began to explore they encountered this clause in the commercial license terms (emphasis mine):

"You must purchase a Qt Commercial License from us or from one of our authorized resellers before you start developing commercial software. The Commercial license does not allow the incorporation of code developed with the Qt GNU LGPL v. 2.1 or GNU GPL v. 3.0 license versions into a commercial product."

This made no sense at all to our community members. Here's what happen's in real-life with open source libraries which have a dual-license structure:

1. Team start developings an application which they think they might make commercial later, but maybe they're not sure, or they're not sure precisely of the form that will take
2. In the early stages, perhaps while in incubation or while prototyping, team evaluates and tries out a number of libraries. Normally, open source licenses like the GPL and LGPL do not require any specific actions on the part of the developer, unless they distribute the end results (which at this stage, they haven't yet). The focus is on startup tasks, not finalising a license model.
3. Later on when their commercial plans firm up, they'll decide whether they need to license some of these open source libraries under an alternative license or not. Usually there are a couple of variants, either:
- 1. They make the decision before they distribute any copies of the software, so they haven't at that stage needed to take any action to comply with the LGPL/GPL, so will buy an alternative license in order to start distribution, or
- 2. They decide later on, after distributing under and complying with the open source license, that they want to offer a different version of their software (maybe a version 2.0, or a premium edition) under alternative terms, for which they need to purchase an alternative license

It is *extremely* common for people to make these decisions some way into the development. It's very, very uncommon for people to make firm decisions before they write a single line of code, because they don't know before they at least build a proof of concept whether this is the route for them. The whole point of open source is that it's perfect for prototyping and trying out ideas before committing to a business model. Therefore, the Qt commercial license clause is completely at odds with the way these things usually work. Essentially it's asking people to decide long before they're ready.

So, because of this we're getting a lot of concern in the community. People who are 100% happy with the LGPL aren't concerned, but those who like to keep their options open will find that clause a deal-breaker. What is the reasoning behind it, and can it be changed?

[PolyVox]

While Qt was still under the GPL there was a similar clause preventing the switch to a commercial license. In this case I think the rational was quite straightforward - they wanted to avoid the scenario where by a company with 10 people spends 5 years developing a piece of software, then buys a single license for one developer which they use to compile a commercial version of the software which they sell. Because Qt licenses were sold as development licenses (rather than runtime ones) they have no only sold one instead of 50.

Having now switched to the LGPL, I can see a similar concept applies. For example, a company could have many developers working with the LGPL version and then by a single commercial license so that they can claim support. Obviously this would be hard for Nokia to manage, so they prevent the scenario by making the two licenses non-mixable.

I'm not daying it makes sense, but I think that is their logic.

[nullsquared]

For example, a company could have many developers working with the LGPL version and then by a single commercial license so that they can claim support.

You can get the exact same support for LGPL as their commercial license.

[jacmoe]

Support can be bought separately when using Qt LGPL. Which is nice.

@Sinbad: Thanks for using your Qt contact. This is indeed a strange quirk in their licensing policy.

[milliams]

I suspect it's simply a relic from the old GLP/QPL days. Back then (as PolyVox said) is made a certain kind of sense and while it may still make a tiny bit of sense, it's not enough and I suspect it's simply been overlooked.

[syd]

digging up this thread, as I'm pretty much concerned of QT's Lgpl flavor.
I'm developping a tool, that I have no idea where it's going at.
I first started using WPF, as .NET is my main tech.
Then I started thinking making it cross platform would be great.
winform can be used with Mono, the problem is that I chose C++/CLI which isn't part of mono.
now I start looking at QT, but this license thing puzzles me.
I won't patient enough to go with wxWidget ot gtkmm.

so... now that some time has passed, Jacmoe and stealth, no regret of migrating ogitor to QT?

[jacmoe]

It was a very good move, IMO.

[syd]

I played with the samples, very impressive, beautiful API, the temptation is surely here

[stealth977]

Qt is a crossplatformer's dream, as we showcased, it is even possible to mimic WPF or Fluent UI with it or any GUI you like, its only problem is its License, which can be avoided if you are not going to go commercial with your product...

[jacmoe]

Small correction to that: If you don't plan to go statically linked commercial.
LGPL allows dynamic linking when used commercially.