3 ms·
The main rationale is definitely the license. The existing bindings for Qt Widgets (therecipe/qt and kitech/qt.go) are LGPL. That's just really difficult to use
by mappu 2y ago
The main rationale is definitely the license. The existing bindings for Qt Widgets (therecipe/qt and kitech/qt.go) are LGPL. That's just really difficult to use in Go where static linking is the default behaviour.
The other bindings have some strange behaviours when I checked them closely.
- therecipe/qt: The design of the "qtbox" runtime for therecipe/qt, introduced before the maintainer went MIA. Now that we know the Jia Tan xz story, it's my hope that MIQT can be a "nothing up my sleeve" binding with a clear source code supply chain, with no prebuilt binaries.
- kitech/qt.go: The rationale for their version was to focus on compilation speed, but with GOCACHE this is no longer really a problem. It also seems to be unmaintained.
- wiz21c 2y agohttps://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami... You can have the LGPL'ed code but the price to pay is that your users give your objects files (i.e. pre-link stuff; but not the source code) so that your users can modify the LGPL code and rebuild your project with the modifications. Moreover: https://pkg.go.dev/cmd/link https://pkg.go.dev/cmd/link So it seems that you can have access to the object files. Overall, it is possible to make your bindings LGPL. I understand this is a bit trickier and not very user friendly. Or you could dual license. But well, it's a political choice, so I won't try to convince you :-)