To be slightly pedantic, you are not required to pay for it just because you are selling something. The requirement is only that you comply with the terms of the GPL license by releasing source to any modifications that you ship.
... or the source to any code that uses PyQt. Nobody knows. It hasn't been tested in court. I'm not sure it's even been tested with C code that links against a GPL library. With Python you're another step removed because it's dynamic and the linking doesn't happen until it's on the consumer's computer.
Thats how the law work. A copyright owner go to a judge and say "The accused sold work based on my copyright" and the accused has to bring up the GPL as proof that they have permission, or they argue that the new combined work do not include any copyright-protected elements of the original. Its a grey area by design.
Linking technology itself is actually rather irrelevant to the legal questions that a court general ask in defining copyright. FSF happen use it as a bright line in the sand on where they will enforce the license, but any author can make their own decision on that matter. Game companies has for example gone after mods that inject itself through windows libraries, arguing that the mods purpose and existence is dependent on the original game and thus created a derivate work.
There was a historical case when a person legally bought a painting and cut it into several pieces only to stitched them together into a mosaic. The court judged it as a derivate work and thus requiring additional copyright permission from the author.
As with other gray areas in copyright, derivative work also have semi-exceptions. Compatibility is one. Since there is multiple different C standard libraries, it would be hard to argue that a program is specifically a derivative work of one. It would also be very easy to demonstrate the works independence by simply using a different standard library.
PyQt brings a interesting question but in the end I doubt it would be that much of a gray area. In theory you could make a program that is only compatible with Qt but don't actually depend on it, but in practice I suspect most such program do not start, operate, and function if you remove the Qt parts. In such cases I expect the accused will have a hard time arguing that the final work when used has no copyright-protected elements of Qt.
But by it being GPL, you also have to release the source code of your potentially proprietary code as GPL. It's LGPL where you only have to release the modifications to the library.
If you statically link to an LGPL library, then the entire codebase (your code and the library) must be covered under an LGPL compatible license.
If you dynamically link to an LGPL library, then only the library must be under an LGPL-compatible license (ie if you modify the library, those modifications must be made available), but your own code that links to the library can be under any license you wish.
This is because the LGPL considers statically linking as a single work, while dynamic linking as multiple works, which can be licensed independently.
GPL:
Regardless of linkage, your code must be under a GPL compatible library.
The GPL considers the software as a single work regardless of linkage.
> If you statically link to an LGPL library, then the entire codebase (your code and the library) must be covered under an LGPL compatible license.
This isn't right. You can statically link proprietary code to LGPL libraries and the LGPL license does not "infect" your proprietary code.
The only thing you have to do if you go this route is ensure that the people receiving your combined work are able to relink any modified version of the LGPL pieces. This can be done, for example, by providing object files for the proprietary pieces and a script to link them to the LGPL pieces, upon request.
