3 ms·

> the competing library is "soon" to release a commercial license No, after many years this never became available, and the maintainer went missing, taking the

by mappu 2y ago

> the competing library is "soon" to release a commercial license No, after many years this never became available, and the maintainer went missing, taking the copyright with them. If it was really possible to buy a commercial license it's possible I might not have bothered to make the binding. My hope is that by choosing the MIT license for my bindings, one commercial app in the world will choose to use Qt Widgets instead of Electron, that does in small part something for the climate.

ForHackernews 2y ago
Isn't Qt still proprietary or semi-proprietary?
- jenadine 2y ago
  No. (There might be side projects like the squish test framework or the MCU port that are proprietary, but Qt itself is fully free software)
- jonathanstrange 2y ago
  This discussion is about the Qt binding library for Go, not Qt. The existing Qt binding they're talking about is LGPL and cannot be bound dynamically, and therefore makes the distribution of proprietary software impossible even with a full Qt license. This new binding alleviates this problem because it's MIT licensed. You still need to adhere to Qt's licensing, i.e., buy a commercial Qt license or bind Qt dynamically like most people do. Qt has a commercial and a LGPL licensed version.
- zerr 2y ago
  No. Just Qt Company hides this as much as they can.
  - prmoustache 2y ago
    It is only proprietary if you are building proprietary code AND statically link to it but open source/free (LGPL) if you are building software with a compatible license or are linking dynamically. I think it is fair.
    - michaelsbradley 2y ago
      LGPL doesn’t forbid linking statically with proprietary code.
- mappu 2y ago
  Qt Widgets is GPL since Qt 2.2 in 2000, and LGPL since Qt 4.5 in 2009.
- nikanj 2y ago
  Most of Qt remains available under LGPL, but the Qt company does their best to dissuade you from using it without a commercial license. They have succeeded in convincing me, for example. I don't want to build anything on a platform where the vendor is trying to drive me away
jenadine 2y ago
I guess you were not serious about the climate, as this will have no measurable effect on it, and with things like Jevons paradox [https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox] could even have the opposite effect (more people using the app more because it is more usable) But yes, for the love of your users, don't make an app using electron :-).
- Fraterkes 2y ago
  Vacuous comment. What action that an average person can take will have a "measurable" effect on the climate (excepting eco-terrorism)? In aggregate this kind of stuff is still meaningfull.
  - jenadine 2y ago
    > In aggregate this kind of stuff is still meaningfull. No, I don't think it is. The scale is so small that even if every electron application was suddenly replaced by an equivalent super lightweight one, I claim it would make no difference for the climate. Other things can make a difference in aggregate, like eat less meat, using better mode of transportations, ... But I don't think the CPU cycles wasted by electron makes any difference, even in aggregate.
    - varjag 2y ago
      Electron apps are probably responsible for multiple Gigawatt-hours of wasted energy annually.
jcelerier 2y ago
> My hope is that by choosing the MIT license for my bindings, one commercial app in the world will choose to use Qt Widgets instead of Electron I still do t understand this logic. When you combine MIT and LGPL you don't get MIT, you get MIT+LGPL so now you have to take care of both licenses. Electron's LGPL parts don't magically disappear - when you start an Electron app all the things that happen from main() up to executing the first line of your js app code are LGPL
- tracker1 2y ago
  Because this library supports dynamic linking, but can itself be statically linked, which is a default behavior for go. Trying to dynamically link a go library that dynamically links, or even statically links to Qt is just an extra level of effort for application developers. This library will be easier for developers to create applications which comply with LGPL of the upstream library without adding additional burdons.

by mappu 2y ago

ForHackernews 2y ago

Isn't Qt still proprietary or semi-proprietary?

jenadine 2y ago
No. (There might be side projects like the squish test framework or the MCU port that are proprietary, but Qt itself is fully free software)
jonathanstrange 2y ago
This discussion is about the Qt binding library for Go, not Qt. The existing Qt binding they're talking about is LGPL and cannot be bound dynamically, and therefore makes the distribution of proprietary software impossible even with a full Qt license. This new binding alleviates this problem because it's MIT licensed. You still need to adhere to Qt's licensing, i.e., buy a commercial Qt license or bind Qt dynamically like most people do. Qt has a commercial and a LGPL licensed version.
zerr 2y ago
No. Just Qt Company hides this as much as they can.
- prmoustache 2y ago
  It is only proprietary if you are building proprietary code AND statically link to it but open source/free (LGPL) if you are building software with a compatible license or are linking dynamically. I think it is fair.
  - michaelsbradley 2y ago
    LGPL doesn’t forbid linking statically with proprietary code.
mappu 2y ago
Qt Widgets is GPL since Qt 2.2 in 2000, and LGPL since Qt 4.5 in 2009.
nikanj 2y ago
Most of Qt remains available under LGPL, but the Qt company does their best to dissuade you from using it without a commercial license. They have succeeded in convincing me, for example. I don't want to build anything on a platform where the vendor is trying to drive me away

jenadine 2y ago

I guess you were not serious about the climate, as this will have no measurable effect on it, and with things like Jevons paradox [https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox] could even have the opposite effect (more people using the app more because it is more usable) But yes, for the love of your users, don't make an app using electron :-).

Fraterkes 2y ago
Vacuous comment. What action that an average person can take will have a "measurable" effect on the climate (excepting eco-terrorism)? In aggregate this kind of stuff is still meaningfull.
- jenadine 2y ago
  > In aggregate this kind of stuff is still meaningfull. No, I don't think it is. The scale is so small that even if every electron application was suddenly replaced by an equivalent super lightweight one, I claim it would make no difference for the climate. Other things can make a difference in aggregate, like eat less meat, using better mode of transportations, ... But I don't think the CPU cycles wasted by electron makes any difference, even in aggregate.
  - varjag 2y ago
    Electron apps are probably responsible for multiple Gigawatt-hours of wasted energy annually.

jcelerier 2y ago

> My hope is that by choosing the MIT license for my bindings, one commercial app in the world will choose to use Qt Widgets instead of Electron I still do t understand this logic. When you combine MIT and LGPL you don't get MIT, you get MIT+LGPL so now you have to take care of both licenses. Electron's LGPL parts don't magically disappear - when you start an Electron app all the things that happen from main() up to executing the first line of your js app code are LGPL

tracker1 2y ago
Because this library supports dynamic linking, but can itself be statically linked, which is a default behavior for go. Trying to dynamically link a go library that dynamically links, or even statically links to Qt is just an extra level of effort for application developers. This library will be easier for developers to create applications which comply with LGPL of the upstream library without adding additional burdons.