Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Miqt: MIT-licensed Qt bindings for Go

github.com

Post reply on HN
Print view View original

21–30 of 92 posts

Re: Miqt: MIT-licensed Qt bindings for Go

#21

Post by rob74 »

jenadine wrote: post #18
rob74 wrote: post #15

Earlier quoted context omitted.

Well yeah, that's the old "open source" vs "free software" schism: Go itself being permissively licensed, there's a lot of interest in having libraries that also come with "no strings attached".

This is not about "open source" vs "free software". This is about "permissive" vs "copyleft"

I'm probably oversimplifying things, but for me "permissive license" (MIT, BSD) is equivalent to the term "open source", and "copyleft license" ((L)GPL) "free software". I know that the term "open source" also includes (L)GPL-licensed software, but the "free software" advocates resist being lumped together with software that they perceive to be less free, so they very much prefer "free software".

Re: Miqt: MIT-licensed Qt bindings for Go

#22

Post by ForHackernews »

mappu wrote: post #19
azalemeth wrote: post #11

I slightly lament the rise of MIT or BSD licensed middleware like this. It's undoubtedly great for the developers and organisations in question, but there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license. This already exists for Go and Qt, and the competing library is "soon" to release a commercial license that would be…

> 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 i…

Isn't Qt still proprietary or semi-proprietary?

Re: Miqt: MIT-licensed Qt bindings for Go

#23

Post by jenadine »

mappu wrote: post #19
azalemeth wrote: post #11

I slightly lament the rise of MIT or BSD licensed middleware like this. It's undoubtedly great for the developers and organisations in question, but there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license. This already exists for Go and Qt, and the competing library is "soon" to release a commercial license that would be…

> 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 i…

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] 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 :-).

Re: Miqt: MIT-licensed Qt bindings for Go

#25

Post by ikari_pl »

rob74 wrote: post #21
jenadine wrote: post #18

Earlier quoted context omitted.

This is not about "open source" vs "free software". This is about "permissive" vs "copyleft"

I'm probably oversimplifying things, but for me "permissive license" (MIT, BSD) is equivalent to the term "open source", and "copyleft license" ((L)GPL) "free software". I know that the term "open source" also includes (L)GPL-licensed software, but the "free software" advocates resist being lumped together with software that they perceive to be less free, so they very much prefer "free software".

so less permissive = more free.

gives me something to think about.

Re: Miqt: MIT-licensed Qt bindings for Go

#26

Post by jenadine »

ForHackernews wrote: post #22
mappu wrote: post #19

Earlier quoted context omitted.

> 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 i…

Isn't Qt still proprietary or semi-proprietary?

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)

Re: Miqt: MIT-licensed Qt bindings for Go

#27

Post by jonathanstrange »

ForHackernews wrote: post #22
mappu wrote: post #19

Earlier quoted context omitted.

> 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 i…

Isn't Qt still proprietary or semi-proprietary?

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.

Re: Miqt: MIT-licensed Qt bindings for Go

#28

Post by rubymamis »

mappu wrote: post #7
rubymamis wrote: post #2

> Yes. You must also meet your Qt license obligations: either use Qt dynamically-linked dll/so/dylib files under the LGPL, or, purchase a Qt commercial license for static linking. There is this misconception that you can't statically link under the LGPL. From my reading (non legal advice), LGPL supports static linking - you just have to release your object files alongside the binary to allow people to link them with…

I also think that is legal. But if you are required to distribute additional object files, that does somewhat reduce the benefits of static linking - you might as well use dynamic linking in that case. It's also not completely trivial to do this with the Go linker.

> But if you are required to distribute additional object files, that does somewhat reduce the benefits of static linking

Because of the total increase in size? Maybe one can just share a link from which the object files can be downloaded?

Re: Miqt: MIT-licensed Qt bindings for Go

#29

Post by shagrath »

rob74 wrote: post #17
mappu wrote: post #12

Earlier quoted context omitted.

A lot of kitech's work was in making the large C ABI wrapper. There's another C ABI wrapper already in Debian (libqt5pas) that might be possible to use directly.

Ah, that's a part of Lazarus (the "pas" at the end is a giveaway). Actually I've had this idea for some time that integrating Go into Lazarus might be worthwhile - I was a Delphi developer before I "jumped ship" to web development, but I still like the effortless way of building GUI applications with a proper GUI design tool, and Go's speed of compilation and some syntax elements make it appealing for Pascal develope…

You might like this : https://github.com/ying32/govcl

Re: Miqt: MIT-licensed Qt bindings for Go

#30

Post by zerr »

mappu wrote: post #7
rubymamis wrote: post #2

> Yes. You must also meet your Qt license obligations: either use Qt dynamically-linked dll/so/dylib files under the LGPL, or, purchase a Qt commercial license for static linking. There is this misconception that you can't statically link under the LGPL. From my reading (non legal advice), LGPL supports static linking - you just have to release your object files alongside the binary to allow people to link them with…

I also think that is legal. But if you are required to distribute additional object files, that does somewhat reduce the benefits of static linking - you might as well use dynamic linking in that case. It's also not completely trivial to do this with the Go linker.

You are not required to distribute those along with your app. You can just have them available for download separately if anyone needs it. LGPL requirement is the ability of the end user to relink (not recompile) the executable.
Post reply on HN