I believe your license is incorrect. PyQt is licensed either commercial or GPL, so you would have to either purchase a license or license this under GPL verses the more permissive MIT license you are using.
> No; incorporating or linking against GPL requires that your project-as-a-whole be distributed under GPL. But you can include MIT licensed parts (or another GPL-compatible license) in the project. Also, it depends.
As the quoted part says: the project as a whole (which includes the library itself) need to be GPL, but part of it can be MIT. So the code of the program on GitHub can be MIT.
Under the GPL terms, the derived work becomes GPL (this is why people call GPL infectious or viral). The project may include unrelated MIT components alongside GPL components, but the project itself becomes GPL, along with any derived components (i.e. components making use of the GPL components). It’s kind of the entire point of the GPL. It’s also why we ended up with LGPL, which offers a linking exception.
The virality is something else: It is that you must disclose the source of the whole program that use a GPL only library. And you're doing that with MIT
It doesn't. It just doesn't give you permission to use the GPL licensed code unless you comply and use GPL.
you don't need to dual license it - either it's compatible with the GPL (MIT is) and then can be shipped as part of a GPL program, or it isn't and then you cannot distribute the complete program.
I didn’t say all of its components, I said components making use of GPL licensed components or code. His math code could totally be licensed MIT, depending on how the program is put together. His UI code is inextricably derivative of QT though — you can’t separate the two. So even if that code itself could be licensed MIT (which is not clear to me), practically speaking, it can only be used alongside the GPL component and thus in a GPL work.
In some few situations, I suppose the distinction could matter, though.
That said, does it even count since he's not distributing it (Qt) at all?
Its the whole reason PySide exists, to have a Qt Python library hat is LGPL to allow works that use it not have to be GPL like PyQt does.
> You must license the entire work, as a whole, under this License
"That is, their code can be combined with a program under the GPL without conflict, and the new combination would have the GPL applied to the whole (but the other license would not so apply)."
This is from when Qt still cared about LGPL, i.e. the Nokia days when the aim was to be the commercial-friendly Nokia SDK.
Then it was released under its own QPL license, and KDE negotiated that if Qt went bankrupt it would change to an MIT license.
Finally it was released as GPL.
FWIW, I think Gtk+ was independently extracted from Gimp as Gimp Toolkit, but KDE success drove GNOME creation based on LGPL-ed Gtk+, which, as you point out, later put pressure on Qt to be relicensed.
Both of these were struggling in the changing workstation/PC/mobile market, so I don't consider it against Gtk+: eg. Nokia was soon acquired by Microsoft and even Qt version barely hit the market.
Still, I do believe success of KDE and GNOME has had at least some of the effect on getting Qt LGPL-ed: there is little doubt KDE was great marketing for Qt (there was a plethora of Windows GUI toolkits: cross-platform, not so much).
OFC, I was in none of those boardrooms, so it's all speculative ;)
When it comes to Qt vs. GTK: I would guesstimate that at the peak, GTK+ perhaps had around 10 concurrent paid devs? The peak for Qt was in the 100s, from markets like embedded and automotive that GTK+ hasn't really been able to access (yes, I had all the Maemo devices too). And even for its core focus area, desktop apps, GTK+ hasn't seen a lot of adoption outside the Linux niche, whereas there's a seriously large amount of commercial Windows/Mac software using Qt. This is really what I meant.
Bottom line: Most PC users have a few copies of Qt on their computer, and perhaps own a device or two in their home and another in their garage that also has Qt on it. The same cannot be said for GTK+. A computer with GTK+ on it is relatively rare, perhaps in the tens of millions vs. billions.
It's also worth noting that users who migrate away from Qt do it to either Flutter (because of more permissive licensing - BSD - or mobile capabilities) or Electron (to share tech with their website) or Unity/Unreal (because of the rendering capabilities), but not to GTK+. Users who migrate away from GTK+ often migrate to Qt (e.g. Wireshark and a couple of others). I can't think of an example of anyone moving to GTK+ from really anything else (probably exists but likely minor). To me that means that while Qt has fierce competition, GTK+ is not really among it.
And it's certainly a valid claim that Qt is more omnipresent than Gtk+ today.
Thanks for the lovely chat, I enjoyed going back ~20 years :)