In 2018 if I use C++ Qt 5.10.0 to build a closed source application requires open source or commercial license?

Question

I currently have a C# application that I want to convert over to Qt/C++ 5.10.0 but I am having an issue with QT licensing. This application is given away for free, but it has a service that the user can upgrade to gain more features but it's not mandatory.

My application is closed sourced, meaning that we don't share the source code of the product because this would lead to hacking and people stealing the service. Or worse competitors figuring out what took me years to develop.

Scenario #1 - Open Source - Dynamic Linking

I think I can develop the closed source application as long as I dynamically link against the framework, meaning that the customer can change the framework of QT if they choose. This makes the software hackable because they can change the QT Framework to include hacks that reveal almost anything and to include changing the function of the main developed program. Also if I made any changes to the Qt Framework I would need to make those changes open source.

There is so much discussion on this matter. I am not sure if I have to open source my product or just provide links to QT Framework and cite my program is built on Qt. If I have to open source my program it's not worth even starting to build with Qt since I can't protect it.

Scenario #2 - Commercial License - Static Linking

To combat this, I thought this would mean I needed a commercial license. With a commercial license, we could statically link against the framework and have everything in the .exe, I know this is not hack proof, but it makes my application a lot harder to hack and that's the goal. In this scenario, I could make all the changes I wanted to the QT framework without having to share anything.

After I bought a license for the commercial version I discovered that I can't use static linking because one of the main components uses WebEngine and it does not support static linking after Qt version 4.7. So I am back to Dynamic linking again as the only option?

What License Can I use with these options?

1. I don't plan to make any changes to QT Framework. If I did I would submit changes and provide source code for the changes, with no problem.
2. I don't want to provide source code to my actual program, but it can be easily hacked anyway if I use dynamic linking anyway.
3. I don't mind providing a link to Qt or showing the logo.
4. I don't mind buying a commercial license but I feel a little heartbroken because I can't use any of the features of a commercial license to protect my code. If I am reduced to dynamically linking I prefer to use the open source (free) version. If only the WebEngine was able to statically link, this question would be a no-brainer.
5. I want to protect my source code in some way to make it difficult for hackers. I want the extra level of protection, so I can sleep at night knowing that while my application is not hack proof, it's a bit harder for a script kiddie to decompile the application.
6. The software is given away for free but it does have an option to upgrade and use additional services from our main server. Most of the heavy lifting is actually done on our server.
7. We actually make less than $5,000 a year. We do not see our software grossing over $50,000 anytime soon since it's a very tight niche market. This is our hobby project that has grown over the years.

What are my options if I wanted to continue to use QT 5.10.0+ ?

In an effort to try to lead the questions on what can and can't be done and what's actually hearsay.

What I can do can do in the open source version.

1. Consult a lawyer. There are so many twists and turns only a lawyer may understand it.
2. No Support from QT Support Team, you're on your own. You may gain help from other users in the forum of QT which is still pretty good.
3. You can develop a closed source project but you must link dynamically, where anyone can reapply different modified/open QT Framework versions for relink. You may statically compile the open source version as long as you provide full source code so others may also compile your complete code. No private code allowed if you do this option.
4. As long as you don't make changes to the QT Framework you do not have to provide any source code.
5. If you modify the QT framework you must submit the changes to QT and provide your software and the QT framework as open source, because your software is not relinkable until the changes are made public.
6. You can code sign your own private program and the QT bindings, DLL/LIB and other sources, but you are not allowed to modify your private code to prevent modified versions of the QT Framework to dynamically relink with your code. Your private code has to remain open and relinkable.
7. You don't have to display the Qt Logo, but it's highly recommended by QT. You may not hide file names that would allow anyone to find out you're using QT.

I must have a commercial version if I wanted to do this.

1. No lawyer needed it's pretty cut and dry.
2. You get limited support if you're an INDIE user and full support if you're not a INDIE user.
3. I must have a commercial version for a closed source for profit to link statically.
4. Make all the changes you want and keep everything private.
5. If you have to dynamically link because you need modules such as WEBENGINE, you can code sign DLL/LIB and other resources and if the code sign changes, you can prevent your software from running. You can restrict QT Framework versions from Modifications.
6. Displaying the QT Logo is optional, you can hide all aspects that you're using QT.

Sources..

1. https://www1.qt.io/terms-conditions/

2. http://blog.qt.io/blog/2018/01/11/protecting-qt-application-device-hacking-part-1/

3. https://www1.qt.io/qt-licensing-terms/

Answer 1

If you choose to use the Qt library under the open-source LGPL license, you may either statically or dynamically link it. However, both of these approaches come with requirements:

• If you statically link the library, then you are probably creating a derivative work of the library and would need to release all of your source code that is linked to the library. (Note that when and whether static linking creates a derivative work is a controversial legal topic, but the most conservative reading is certainly that safest.)
• If you dynamically link the library, you do not need to share any of your source code, but you must make it easy for the user to replace the LGPL library with a modified version. If you modify the library, you have to share your changes to the library, but not all your application code.
  • These requirements also apply if you statically link, but would be automatically fulfilled by sharing your complete source code.

If you don't want to meet either of those requirements, then you should use a commercial license instead.

You've also stated that even if you bought the commercial license, there is a a technical reason why it cannot be statically linked. If that is the case, then the open source version likely has the same problem, and static linking simply isn't possible at all. However, with the commercial version, you could try to make re-linking difficult (via some kind of obfuscation, perhaps) which the LGPL's "easy re-linking" requirements would disallow. (Consult the commercial license terms to ensure that you can actually do that, though.)

Answer 2

App Store does not care which license you use. It is the users of your application and the Library authors who care. The main point of the LGPLv3 license is that the end users must have the possibility to replace the library with their own modified version. This is very important to understand, dynamic / static / everything else is just distracting.

Let's move to Qt. It is available with LGPLv3 license on major Desktop (Windows, OSX, Linux) and mobile (iOS, Android) operating systems. Suppose you develop an application and want to keep your source code closed. On the Desktop you can link dynamically to Qt libraries. When the end users install your application, they can replace Qt libraries in the following way:

1. Compile their own version of Qt libraries
2. Navigate the the location where the application is installed
3. Replace original Qt libraies that were shipped with your applicatoin with their own modified versions

Looks easy, right? The main goal of LGPLv3 is achieved. The user can replace libraries.

Moving to the mobile platforms, starting with Android. Even though you link dynamically to the Qt libraries, we now have a small problem. The user can not navigate to C:/Program Files/YourApp and replace Qt libraries, because it's Android. Rooting is not an option, since it doesn't work on every device (and might not be legal). Remember, the main goal of LGPLv3 is to give the users ability to replace the library and run the modified version of your application on their device.

Solution? Provide .apk file to every user who installed your application with detailed instructions on how to:

1. Unpack your .apk file
2. Replace Qt libraries
3. Zipalign / pack / signtool to a new .apk
4. Install .apk with modified Qt libraries

Let's talk about iOS. Many say it is not possible to use LGPLv3 with iOS because of static linking. Wrong. Again, you just need to give the end user the possibility to replace Qt libraries. How? Provide your object files for the end user to relink. Or even better, put all your application code and resources in a separate Qt Quick plugin which will compile in a static library archive (technically just all object files concatenated together) for iOS. Then for every user who installed your application you have to provide instructions on how to replace Qt libraries:

1. Download project files and object files from your website
2. Download XCode and developer tools from Apple website
3. Replace Qt libraries
4. Deploy application to your device

Before this was not possible because in order to deploy on the device the user had to enroll Apple Developer Program. But this is not the case any more. You can launch your app on a device using a free Apple ID account

The end user rights are protected. They can replace Qt libraries. Just make sure you do required steps:

1. Mention in your application that you use Qt libraries and also mention you use them under LGPLv3 license. Provide a link to LGPLv3 lincese.
2. Make sure your setup of replacing Qt libraries work. Set up a clean virtual machine and do everything step by step. Document it for the end users.
3. When the users who downloaded your application want to replace Qt libraries, provide them everything so they can do it.

Actually I don't think anyone would care. But you have to be ready just in case. Do not scream you use Qt LGPLv3 on Qt forums, but make sure you have it visible somewhere down in your application's "About" screen. Qt company does not have resources to scan every application from the App Store if it uses Qt or not. Neither they will touch you if you are a small-near-zero-profit. They have more important things to do.

It is very dissapointing however to see absolutely no help from people who work in Qt on the LGPL subject. Most likely all developers were instructed to answer "IANAL, please contact our legal department". The legal department will tell you - buy our commercial license, it's the only option. On the Qt website you can find Obligations of the LGPL. I am not surprised, there is no word about static linking and providing object files for re-link on this page. Qt company simply prefers not to tell anyone it is possible.

Also thinking about MeeGo and Blackberry, there was no problem with developing closed source mobile apps that use Qt and publishing them in respective app stores. No commercial license needed.

Update: This has been done before. LGPL is possible with static linking and App Store. https://news.ycombinator.com/item?id=4302517