16

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/

10
  • 1
    Qt Open Source is LGPL, so as you already pointed out, you may use it with your closed source poduct as long as you link it dynamically and allow the user to supply her own verison of Qt. You are not obligated to show Qt's logo in your application.
    – Brandin
    Jan 24, 2018 at 17:39
  • "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" - Qt Commercial includes a source license that allows you to change the code, link statically, and not distribute your changes. However, the details of the Qt Commercial product are not open source and are thus off topic here.
    – Brandin
    Jan 24, 2018 at 17:40
  • “I want to protect my source code” – from what exactly? I think you are overestimating the motivation of legitimate users to dig into your software. And for malicious users, the only good reason I can think of is to inject some malware and then distribute the infected version of your software as a trojan horse, leeching off your reputation. But that can't be prevented entirely in any case. Offering convenient downloads (e.g. on your website and through app stores, not on third-party sites) is going to be a much better measure to prevent that than any obfuscation.
    – amon
    Jan 24, 2018 at 21:22
  • My software is part of a membership package where members compete against each other to win prizes, cash, and credits. Currently, they dig into the C# version, so I guess I just want to make it a bit harder if possible. Jan 24, 2018 at 21:48
  • 6
    @DavidEaton Design safeguards in that don't depend on the secrecy of the source code. For example, add authentication and a referree system that warns or bans users that do suspicious things. It's the same principle with any game, really. There is almost always a referree who makes sure everyone "plays by the rules." In games with complete information, another possibility is that each player can referree each other player. In chess, for example, it would be impossible to cheat by modifying your client to give you an advantage; your opponent would see that you're violating the well-known rules.
    – Brandin
    Jan 24, 2018 at 22:11

2 Answers 2

15

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.)

6
  • What would be the requirement for "making it easy for the user to replace the LGPL library with a modified version"? Is for example contacting support to do it for you an acceptable solution in your opinion?
    – pooya13
    Feb 11, 2020 at 7:50
  • @pooya13 The LGPLv3 says in 4(d)(0): "Convey... the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work..." -- I think if the user has been legally or technically forbidden from relinking it themselves, then the user has not been given "a form suitable to... relink the Application".
    – apsillers
    Feb 11, 2020 at 12:18
  • Does that apply to dynamic linking? Because I think I saw somewhere that for dynamic linking you don't need to provide object files of your own code. And if the software is running on a closed system, does that mean the user would need to have access to deploy the new version themselves? (for example by having ssh access?)
    – pooya13
    Feb 12, 2020 at 4:53
  • @pooya13 I'll admit, it's been a long time since I used a C compiler. The main thing is that the user needs to be able to relink your application with a modified LGPL library, so if you can satisfy that requirement without supplying object code, so be it. It was always my understanding that dynamic linking meant that you could (merely) supply your app as object files for relinking instead of supplying the full source (which would be necessary for the user to re-employ static relinking). But again, I understand the legal specifics much more than the specific linker mechanism to fulfill them.
    – apsillers
    Feb 12, 2020 at 12:21
  • @pooya13 As for a "closed system" if the user can receive the object code of the executable in any form, they are entitled to receive the source of the included LGPL library (and sufficient material of your application to relink it). If the user can't view or receive the executable (e.g., they interact with it indirectly through a Web API that does not allow download of the executable) then distribution can't occur and you don't have LGPL requirements (which only trigger on distribution).
    – apsillers
    Feb 12, 2020 at 12:27
19

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

4
  • Too much focus so much on App Stores and iOS, and unplaced speculation about Lars Knoll just based on an off-hand remark.
    – Brandin
    Feb 1, 2018 at 9:24
  • I agree @Brandin, I removed unplaced speculation
    – psyched
    Feb 1, 2018 at 10:11
  • This is very interesting.. While I can't build statically because of the WEBENGINE, I wondered how an mobile application would work. I assume the .apk file is the source file? Just Guessing here. So in theory someone could read your source code and build their own version based on your existing code? If not, I was under the impression to link statically you had to release your protected code as open source. Meaning you could not have a closed source project without violating the rules set after QT 5.4 or Qt 5.7 I believe ? The cite link to ycombinator is over 5 years old. Feb 1, 2018 at 18:10
  • .apk is the binary archive that contains executables and resources. You can link statically when using LGPL, but you need to provide your object files for to relink. This is not the same as providing the source code. Object files contain assembler plus some extra information. You are not revealing too much. Also LGPL did not change over 5 years, base things are the same.
    – psyched
    Feb 2, 2018 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.