19.3. The License Usage by Qt

19.3.1. The FreeQt License

There were actually two versions of the Qt library: a commercial version and a free version. If the recipient's product was closed source (that is, it was distributed under a license that was not a free software license), they were required to purchase the commercial version of Qt. This version restricted further redistribution of either the original source or modified versions of it and thus failed two of the three requirements of Open Source.

The free version of Qt fell under the FreeQt license. This version was available only if the recipient's product was distributed under a free software license. It permitted the redistribution of Qt and access to the source code. However, it did not allow modifications of Qt to be redistributed. That final clause does not satisfy the requirements of the FSF definition and thus, it is not a free software license.

It is interesting to note that even though the FreeQt license prohibited distribution of modified versions, several modified versions were widely distributed with official permission from Trolltech. The most common "alternate" distribution was used by the Korean speaking world in order to use Kanji characters with KDE 1.x even before Unicode support was added. So while technically it was impossible to modify Qt, the reality of the situation was that Trolltech rarely refused patches and was very willing to allow exceptions on a case-by-case basis when needed.

19.3.2. The Q Public License (QPL)

The QPL was introduced with Qt 2.0. It was designed with the help of several Open Source and free software notables to be an official Open Source license. The old FreeQt license already met the redistribution and access to source code requirements of Open Source, and the QPL added the "modification" capability.

The design goal of the QPL was different from the design goals of the GPL and LGPL in that Trolltech wanted to protect the "good name" of the Qt library while still allowing free redistribution and modification of the library. It accomplished this by requiring that all changes to the Qt code must be distributed separately from the code itself. That is, the Qt library must always be "pristine" before your changes are applied to it. This is intended to protect the intellectual property of the Qt name.

The QPL had one final design goal: the patch clause was designed to make sure that all users may use modified versions of Qt, including commercial users. If another Open Source license had been used, then closed-source companies would not have been able to use any changes to Qt. Using patches, Trolltech could ensure that there was always one unique Qt library, not different libraries for different kinds of development.

The method in which you accomplish this varies, based on how you want to redistribute the library. The most common way now is to put the Qt library in a public source repository such as CVS. Because the CVS system stores all changes as incremental "patches," the original Qt is still there. The KDE project maintains a development version of Qt in its CVS repository in this manner. Since nearly all large Open Source projects use CVS, this means that it is trivial for them to use modified versions of Qt.

If, however, you want to distribute your modified version of Qt in a complete package (for example, a tarball or a Zip file), you will commonly include your changes as patch files. You may have scripts that automatically apply your changes to the library as soon as the user unpacks them, but the original Qt must be available untouched to the user.

The recommended way to distribute a modified Qt is to use a packaging system such as the Red Hat Packaging Manager (.rpm files) or Debian packager (.deb files). Both offer ways to release source with patches applied automatically to an original. This makes distribution of a modified Qt almost no different than distribution of any other part of your project.

Also note that this only applies to source modifications. The binary versions of a modified Qt may be released as-is. That is, the end user doesn't have to worry about any of this. It is only a concern for developers.