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.