therecipe / qt

Qt binding for Go (Golang) with support for Windows / macOS / Linux / FreeBSD / Android / iOS / Sailfish OS / Raspberry Pi / AsteroidOS / Ubuntu Touch / JavaScript / WebAssembly
GNU Lesser General Public License v3.0
10.39k stars 736 forks source link

legal requirements for dual licensing #259

Open therecipe opened 7 years ago

therecipe commented 7 years ago

@bclermont @m8m5 @jordanorelli @akamensky @5k3105 @longlongh4 @aebruno @nnvn @hvnsweeting @KellyLSB @pekim @joesis @mixedCase @xland

Hey

I'm planning to offer the binding under a second (additional to the current) commercial license. The commercial license will be useful for people/firms who want to distribute their product in binary only form and also don't want/can't meet the conditions of the current license.

And because you directly contributed code, I have to obtain the rights from you to do so first. I also would like to compensate you for the transfer of your rights, by granting you the right to use the binding in the terms of the commercial license for free.

Please let me know if this is okay for you and if you grant me the rights for your code.

Thank you.

therecipe commented 7 years ago

@SimplicityApks

@therecipe can you elaborate on why you chose the LGPL instead of the GPL if you're so concerned about commercial use of the lib?

I think LGPL is the best fit for this, as it's more permissive for open source users then GPL and at the same time more strict for closed source (and/or commercial users) then MPL. LGPL seems to be the golden middle between MPL and GPL from my perspective.

LGPL might be complicated to understand for closed source users, but it's relatively easy to understand for open source users. (Okay, it's not as easy to understand as MIT/BSD but people would have to learn about LGPL sooner or later anyway, when they look into Qt's licenses)

Also LGPL is still much more permissive without static linking than GPL. And on a side note, I'm still pissed that the Go devs stopped working on dynamic linking for Go libs, as I really hoped that they would get it working.

@pztrn

Let me please do a proposal as open-source lover and yet as person who want to make some buck on software written with this bindings in future. Please, allow small companies (for example to companies who have 5-10 employes) and to individual entrepreneurs to use your bindings for free or for really small about of buck (like $5 or $10).

I won't promise nothing, but yeah I would love to offer different tiers and then keep it free/cheap for individuals/startups.

jrmiller82 commented 7 years ago

@therecipe You still haven't addressed the fact that the LGPL is incompatible with statically linked binaries a la Go.

therecipe commented 7 years ago

@jrmiller82 I'm not quite sure what you mean, it's not incompatible afaik. Could you elaborate?

jrmiller82 commented 6 years ago

The LGPL is incompatible with statically linked binaries. Statically linking an LGPL library subjects the whole project to copyleft whereas dynamically linking would not. Go in its current form is mostly statically linked. We already discussed this above.

therecipe commented 6 years ago

Oh, sorry thought there was some new info that I missed. You probably meant "addressed" as in "took action"? If so, then yeah this will still take some time.

shuttleone commented 5 years ago

Hi, it has been a while; Is a new license still planned for this project?

therecipe commented 5 years ago

Yes, I have no fixed date, but maybe sometime in spring/summer 2019 once everything is properly vetted and I'm comfortable handing out licenses.

This also somewhat depends on https://github.com/therecipe/qt/issues/382 since the project probably needs to be rebranded first.

However, I haven't had the time to update the FAQ in the wiki yet to make this clear, but it's already possible to use the binding for proprietary developments without the need for a commercial license. You will only need to compile your programm with the -comply flag, which then dumps some object files generate during the compilation and some small script into a seperate directory. Now you would only need to make these files available to your customers in some form, to comply with the binding's LGPL license as well as with Qt's LGPL license.

But there is some downside I don't want to hold back, namely that these object files contain more infos than your final binary, such as debug symbols and probably full function signatures but I haven't really looked into them that deeply. To test the object files, you will only need to run the helper script which then should create a working version of your binary.

Also this currently only works for windows, linux, mac, ios and android builds iirc, but feel free to open an issue if you run into any problems or you need it to work for some other targets.


Also just to clarify this again, most people won't actually need a commercial license unless they plan to create closed source application and intent to distribute the final binary out-of-house. And in this case they can already use the -comply workaround for free.

All other people who want to use this either in-house or publish their source publicly have no restrictions whatsoever, neither for their license nor for something else. (As far as for this binding's LGPL license, Qt's licenses might have other restrictions for example the iOS builds or some modules such as charts, or the WebAssembly platform support)

disclaimer: IANAL, TINLA and DYOR

shuttleone commented 5 years ago

Thank you. I was unaware of the -comply functionality. This is good enough for me. I would still like to support the project if/when a commercial license is available.

pieceofsoul commented 4 years ago

Hi! As a longtime Qt user, moving from C++ to Go, I was happy to discover this nice Go binding and I would really love to build upon it! Since my current project is required to be distributed as closed source application:

b) a second (commercially) license which allows static linking => doesn't exists yet

Is there any news regarding the planed dual licensing?

develar commented 4 years ago

Yeach... another confirmation that Qt is dead and the reason why Electron wins and why solutions like https://github.com/fyne-io/fyne arise and growing. My app will be open-source, but fact that no clear and simple answer for commercial apps on this binding means that technology is dead and more as a play than a serious solution...

mappu commented 2 weeks ago

Hi everyone. To avoid the LGPL issue with this binding, I've recently started developing a new MIT-licensed Qt binding for Go. You can check it out here: https://github.com/mappu/miqt .