Open Source vs Commercial License

April 5, 2016 — 2 Comments

Qt exists since more then 20 years ! Take a look at the history:

Open Source


Since 1998 the KDE Free Qt Foundation guarantees Qt availability for Open Source Development. It’s great to rely on an Open Source framework – you always can take a look how things are implemented.

Up to Qt 5.6 the LGPL 2.1 was used, from Qt 5.7+ the LGPL 3 will be used.

I’m starting with Qt 5.6 to test the new UI Controls from qt.labs.controls. qt.labs.controls are only a Tech Preview in 5.6 and will be part of Qt 5.7.

Not only LGPL 3 is new for Qt 5.7 – also some Tools (Charts, Data Visualization, …) only available for commercial license before will become Open Source, but as GPL 3. Later this year the QML Compiler will also be included into Open Source license.

There’s a Blog describing all these changes in detail:

What does this mean for your mobile APPs ? Can you use the Open Source version of Qt ?

The answer isn’t easy and I’m not a lawyer !

Here’s a great german blog discussing LGPL 3 and GPL 3 for commercial projects:

Using Qt Essentials and Add-Ons -> LGPL 3

Your own APP can be sold commercial, but the user must be able to replace the Qt Libraries. No one would do this for a mobile APP, but these are the rules which make sense if Qt is used for Device Creation in embedded market.

You can publish your Android APP via Google Play store, if you provide a description HowTo replace the Qt libraries (.so) which means you must provide your APK file together with a recipe HowTo do this.

See also discussion at StackOverflow:

and here’s the recipe:

So for Android there’s a way, but this won’t work for Apple’s App Store AFAIK.

Tools (Charts, Data Visualization, …) -> GPL 3

The story becomes more worse if you’re integrating GPL 3 – licensed tools into your APP. Then your own APP must be GPL 3, so you should ignore these for APPs distributed via Google Play or so.

Business APP In-House-Use 🙂

The story is totally different if your APPs are not distributed via consumer app stores.

I’m developing mobile business apps running in-house in medium-sized companies or enterprises. APPs in this case are distributed via BES12 or similar MDM / EMM solutions. My customers always get the sources, so the Open Source licenses for included Qt libraries can be used without any problems.

Sometimes customers want to get support from Qt, which is part of commercial licenses – in this case it makes sense to get a commercial license.



As we’ve seen: LGPL 3 and GPL 3 are no easy-to-use licenses for mobile Applications – are there alternate ways to go ?

Yes: Qt is also available with a commercial license and because Qt is available for so many platforms, the license isn’t cheap (around 300 € p.month). This is ok for companies like LG using Qt for their Smart TVs or so but not for the typical moble APP developer.

The Good News: starting with Qt 5.6 there’s a new commercial license for small StartUps and Independent Developers:


For me this sounds good and enables me to distribute apps without any problems via consumer app stores. Follow these blog series to see how cool it is to develop x-platform mobile APPs with Qt.

My Enterprise customers on the other side will get the complete source projects and can decide if they want to use Commercial or Open Source license for in-house-use.

← Back (Why Qt for Mobile App Development)

→ Next Article (Prepare for Android (SDK, NDK))

⇐ Home (Overview / Topics)

2 responses to Open Source vs Commercial License


    concerning the compatibility of Qt LGPL and iOS app store:
    iirc the perceived incompatibility comes from the combination of two facts:
    * first, apple didn’t allow the use of dynamically linked frameworks – at least prior to iOS 8 (it seems that this has changed since, so the problem might not even exist any longer for recent devices)
    * second, the perception (sometimes perpetuated by the Qt people themselves) that Qt LGPL would necessarily mean the use of a dynamic linked Qt.
    But the latter is just false. The LGPL actually DOES allow static linking too, even explicitely so. The only thing is that if you decide to do that, it requires you to provide the means for the user to replace the LGPL library, i.e. you have to provide the non-LGPL part of your application either in source form OR as a binary object file so that it can be statically linked with a modified version of the library by the user himself.

    and section 4.d.0 of the LGPL:


    Just came across this. Yes, the LGPL 3 / GPL 3 licensing takes away the ability of the small guy to publish an app., and the commercial license for small startups gives it back, although I would say the $100k limit is pretty low. So low as to be useless in my industry, where high commercial license prices and MOQs are a problem.

    My company’s customers make embedded devices, usually for non-consumer users (think POS terminal etc.), and so are most affected by the “tivoization” restriction – i.e that it must be possible to compile and run modified code (read “any code you like”) on the hardware.

    Turns out there’s a useful caveat in LGPL’s definition of scope to “closed consumer devices”. If the device isn’t for consumer/home use the restrictions don’t apply. See my blog.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s