That would be why there's a 30 day free trial, for potential customers to evaluate with: https://www.qt.io/download/#Licence-anchor

> The license for prototyping seems to be the same one for release. And Qt isn't offering me a free product, their terms are pay then develop your software. At least in my context.

Their standard Qt for Application Development license gives you a free 30 day evaluation period. Also, I don't think any of this encompasses simply examining the free product without use in product development, e.g., reading the APIs, documentation, and source code. That's a lot of freebies, that you don't necessarily get with other commercial products.

> In any event the only issue is the weird quirk of the Qt commercial license preventing you from switching to commercial from LGPL. Which I and apparently a few other people in the thread really didn't get at first.

There's no weird quirk. As they state, "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 have money, they will take your money. But if you want to develop a commercial product and use Qt up front then you have to budget for it. If you can't afford it then use something else. No one is holding a gun to your head forcing you to develop a proprietary product with Qt.

> Will operate properly with a modified version

Sounds like all you have to do is prove your build on your dev machine works with newer versions. Up to the user to update the library on the target machine!

Thanks for digging this up for me :) . However,

0) leaves room for interpretation: when it says "to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work", should we read this as "the very same Version, modified to accommodate some needs while keeping API compatibility in mind" or a much-broader "any later Version, maybe even upstream, that may have received drastic API changes" ?

1) has boundaries: you are supposed to be able to "operate properly with a modified version of the Library __that is interface-compatible__ with the Linked Version". This notion of interface-compatibility seems here to prevent an attacker from saying to a commercial developer: "Here's Qt 42.0, now you will update your code for free for me so that it runs on it". Doesn't it?

More broadly, do you know of any lawsuit where these points were used to successfully prove non-GPL compliance and require more work from a commercial user?

EDIT I'm asking this (and my initial question) because it seems such a clause w/should have absolutely deterred commercial developers from using GPL libraries at all. Not starting a flamewar, I know MIT/BSD/Apache libs are generally more reassuring and popular in commercial software, but GPL code keeps being used by commercial software under the basic "We'll mention usage of the GPL lib in the docs, and will either leave the lib untouched or publish our modifications" promise. This condition as you interpret it seems much more chilling, I'm surprised to hear about it and would like to understand how severely it's enforced.

That is very interesting. Note that they are not precluding you to switch, but they do reserve the right to sell or not sell to you the commercial license after you've used the LGPL. It sounds like an empty threat to me (if you talk to the sales rep and say "I have an internal prototype and I would like to buy the commercial license to finish and distribute it", will they say no?), but one should definitely consider this before choosing to try the LGPL version for early product development.

I think this is mostly meant to avoid having a team of 50 develop an internal version based on LGPL, and then a team of 1 maintain the commercial version, paying a single developer seat.

Note that you can still do a throw away prototype without problems. Some say you should in any case!

It's not standard and it's not pleasant to most ears, but I think over the last 20 (!) years of development the Trolltech guys have tried to make sure they could advance Qt and make a living doing it. I respect that a lot.

OSS was a completely different animal back when this thing started. And it was forward thinking to avoid the whole problem with people demanding free support and bugfixes for open-source code.

At my last company we had this situation. But they are more than happy to sort this out for free if you take a license for the next 2 years.

It would be nice if they had some form of migration publicly stated. For example something like this:

If your project decides to go commercial the initial license term will include a cost of conversion based on the quantity of code already written.

It would be interesting if they expressed that rate as something like:

A gz -1 compressed tarball of the affected source code will be created, the size (in bytes) multiplied by X is the maximum fee we would charge for retroactive licensing.

I choose the wording 'maximum' there as it still allows them to offer better deals under other circumstances.

> It's not really about closing the deal as much as making sure the Trolltech developers were paid during the time you needed their support.

The OSS license doesn't grant you any support from Trolltech, does it?

But do you even need a commercial license to sell your product commercially? It's LGPL, so surely you can just keep the Qt library LGPL. If you're not changing anything at all in Qt (and you really shouldn't be...), and you don't care about getting support (the docs are good enough for you), then why do you need a commercial license at all?

> But then, does this mean anyone can ask for the source of closed-source software that use GPL code, like the ones below? (I just dug two random examples).

If their software is a derivative work of someone else's code then they can't distribute their software without a license from the copyright holder of that code. In the case of the GPL, that licenses them only to distribute their code under the GPL. If they are distributing their software other than under the GPL, then that is copyright infringement (in the same way as if they had made a derived work of some non-GPL code and distributed that), they lose their license, and any holder of a copyright on the code that their software was a derivative work of could sue them for copyright infringement. (In theory they sue for damages; in practice the copyright holder of GPLed code they made a derivative of will usually settle for compliance and an agreement to have their future releases audited).

What constitutes a derivative work is a question for the courts. It's generally accepted that any program that uses a library is a derivative work of that library, and a program that invokes another program at arms length or via a standard interface is probably not a derivative work of that program. The exact boundary is unclear; there's a case to be made that a program that is tightly coupled to another program and invokes it via piped commands might still be a derivative work even though it's not shared objects.

The LGPL is an entirely different license from the GPL.

I didn't look at all the LGPL/GPL code they are using, but your understanding seems correct.

Just listing some possibilities, different projects have different needs. Sure, for most of the cases the dynamically linked open source version works just fine.

Qt for Device Creation needs a license, that one is not available as LGPL. Of course you can use the open source Qt yourself for that, but then you'll be facing a lot of platform work to get Qt running on your device before even starting with the stuff that you actually want to build.

And their rule of thumb is that you aren't worth the sale. Bespoke software is not a bulk commodity. They have a free product. If you're going to be a cheapskate, use it.

The notion of charging by byte, as if software were content farming, shows that you are obviously not a professional.