When developing an application with Qt, understanding the licensing options is crucial, especially if you plan to distribute or sell your software. In this article, we’ll cover the different Qt licenses, dynamic vs. static linking, and how your CLion and CMake setup impacts licensing compliance. By the end, you’ll know how to stay legally compliant and confidently distribute or sell your app.


Qt Licensing Compliance Overview

Qt offers two primary licensing models:

  1. Commercial License
  2. Open-Source Licenses (GPL and LGPL)

1. Commercial License

The Qt Commercial License allows you to create proprietary applications without sharing your source code. This license is a paid option and is ideal for developers who want to:

If you use the Commercial License, you can distribute and sell your app freely, whether it’s free or paid, without worrying about LGPL or GPL requirements.

2. Open-Source Licenses Qt LGPL vs GPL

Qt’s open-source licensing comes with two main options:

GNU General Public License (GPL)

GNU Lesser General Public License (LGPL)

  1. Dynamic Linking: Your app must load the Qt libraries at runtime (e.g., .dll files on Windows).
  2. Library Replacement: Users must be able to replace the Qt libraries with their own versions.
  3. License Notice: Include a copy of the LGPL license and a notice in your app acknowledging the use of LGPL-licensed libraries.

Dynamic Linking vs. Static Linking

The way you link to Qt libraries affects LGPL compliance:

Dynamic Linking

Example in CMake (Dynamic Linking):

find_package(Qt6 COMPONENTS Core Gui Widgets REQUIRED)
target_link_libraries(RambodCraft Qt::Core Qt::Gui Qt::Widgets)

Static Linking

Note: Static linking is generally avoided when using the LGPL version of Qt unless you’re ready to open-source your app or purchase a commercial license.


How Your CLion and CMake Setup Affects Licensing

Let’s analyze a typical project setup with CLion and CMake:

Example Project Structure

RambodCraft/
├── cmake-build-debug/
│   ├── Qt6Core.dll
│   ├── Qt6Gui.dll
│   ├── Qt6Widgets.dll
│   └── RambodCraft.exe
├── LoginWindow/
│   ├── loginwindow.cpp
│   ├── loginwindow.h
│   └── loginwindow.ui
├── MainWindow/
│   ├── mainwindow.cpp
│   ├── mainwindow.h
│   └── mainwindow.ui
├── CMakeLists.txt
└── main.cpp

CMake Configuration

In your CMakeLists.txt:

find_package(Qt6 COMPONENTS Core Gui Widgets REQUIRED)
target_link_libraries(RambodCraft Qt::Core Qt::Gui Qt::Widgets)

This setup dynamically links to the Qt libraries, as evidenced by the .dll files in the cmake-build-debug folder. This means:

  1. You are LGPL-compliant as long as you distribute the required notices and licenses.
  2. You can sell your app without releasing your source code.

Steps to Ensure LGPL Compliance

To distribute or sell your dynamically linked application under the LGPL:

  1. Dynamically Link to Qt libraries (e.g., .dll files).
  2. Include the LGPL License:
  1. Provide Attribution:
  1. Allow Library Replacement:
  1. Reference Qt Source Code:

Example Attribution:

This application uses the Qt framework, licensed under the GNU Lesser General Public License (LGPL).
For more information, visit https://www.qt.io/licensing.

Selling Qt Applications

You can sell your application without releasing the source code if:

If you prefer not to handle LGPL requirements, consider purchasing a Qt Commercial License.


Conclusion

By dynamically linking to Qt libraries and following LGPL guidelines, you can create, distribute, and sell proprietary applications without releasing your source code. Tools like CLion and CMake make it easy to set up dynamic linking, ensuring compliance with LGPL requirements.

For more details, refer to the official Qt licensing documentation:

Stay informed and happy coding!


This article is part of my learning journey at rambod.net. Feel free to share your thoughts and experiences!

Leave a Reply

Your email address will not be published. Required fields are marked *

17 − 16 =