Will Go Plugin Perfectly Isolate Qt LGPL licensing in go?

[hollowaykeanho]

Question:

If I create another binding (or probably work on this and contribute back) using Go Plugin package (https://golang.org/pkg/plugin/), will that perfectly fulfills Qt LGPL license requirements for "dynamic linking"?

So the scenario would be: an app calls the "plugin" via "plugin.Open", then "plugin" call this binding library, then binding library calls Qt LGPL libraries.

p/s: I have a UI project and still this would be the nicest library except Go <--> Qt LGPL dynamic linking issues.

[therecipe]

Hey

If I create another binding (or probably work on this and contribute back) using Go Plugin package (https://golang.org/pkg/plugin/), will that perfectly fulfills Qt LGPL license requirements for "dynamic linking"?

First, IANAL and TINLA but your scenario should be possible AFAIK (under certain circumstances).
You however will need to act with caution, and in doubt it's better to contact a Lawyer.

Generally, this binding as most of Qt are available under LGPL.
So if you comply with this bindings LGPL requirements, then you should automatically comply with the Qt LGPL requirements as well.
(But this is only the case if you exclusively access Qt through this binding, I can't speak for cases in which you directly access Qt, such as when using certain Qt QML Modules for example, which might itself be under GPL or some other license)
Also certain modules such as the Go "charts" module are only available under GPL and an commercial license provided by TQtC, so even if you access these modules through this binding or some dynamic plugin, your code would still be subject to GPL.

I made the setup mention these GPL modules now with 32b5277

So the scenario would be: an app calls the "plugin" via "plugin.Open", then "plugin" call this binding library, then binding library calls Qt LGPL libraries.

Theoretically if you seperate the GUI (therecipe/qt) related code and isolate it into a plugin, then it should be possible to use something like the following to comply with this bindings LGPL license as well as with Qt's LGPL license.

main.go (Uses some form of "dynamic linking" to comply with the GUI related LGPL'ed code, and can now be used for proprietary development)

package main

import "plugin"

//go:generate go generate ./plugin
//go:generate go build

func main() {
	p, err := plugin.Open("plugin/plugin.so")
	if err != nil {
		panic(err)
	}
	f, err := p.Lookup("Init")
	if err != nil {
		panic(err)
	}
	f.(func())()
}

plugin/plugin.go (The license situation for this is a bit more complicate, because it could probably match both definitions "work that uses the library" as well as "work based on the library" and it would greatly depend on the "nature" of this library e.g. what the library does, how it's intended to work and what code it imports. The safest option would probably to open source it under LGPL)

package main

import (
	"os"

	"github.com/therecipe/qt/widgets"
)

//go:generate qtminimal
//go:generate go build -tags=minimal -buildmode=plugin -o plugin.so

func Init() {
	widgets.NewQApplication(len(os.Args), os.Args)

	widgets.NewQPushButton2("HELLO", nil).Show()

	widgets.QApplication_Exec()
}

However, things get complicated if you create functions like these in your plugin:

func SomeButton() *widgets.QPushButton {
	return widgets.NewQPushButton2("someButton", nil)
}

Since it would require the plugin users to directly import github.com/therecipe/qt/widgets as well.
Same thing applies if you make use of qtdeploy, qtminimal, qtmoc, qtrcc, qtsetup with code that is not GUI related.

p/s: I have a UI project and still this would be the nicest library except Go <--> Qt LGPL dynamic linking issues.

Yeah, I'm away that the license situation is suboptimal but it's only really a problem for closed source proprietary developments that are intended to be distributed to the public. Everyone else can simply use the binding without this hassle since LGPL is pretty permissive otherwise.

Also, since I intend to offer a commercial license in the future (sometime in spring, once everything is vetted), please let me clarify that Qt's LGPL license is not the roadblock for commercial projects atm but it's this bindings LGPL license. I will rewrite the FAQ (as well as the Available Tools) wiki pages in the future to better clarify the current (license) situation.

Btw, there is also the option to use the -comply flag to easily comply with this bindings license #259 (comment) without the need to extra seperate and structure your code and without the need to use plugins. (also IIRC plugins currently only work on macOS and Linux)

---

(don't mind me, this is just for the cross reference to some other plugin related issue #587 (comment))

[hollowaykeanho]

First, IANAL and TINLA but your scenario should be possible AFAIK (under certain circumstances).
You however will need to act with caution, and in doubt it's better to contact a Lawyer.

Thanks for the prompted reply. Just to clarify, IANAL too. You did a great job producing this binding.

---

main.go (Uses some form of "dynamic linking" to comply with the GUI related LGPL'ed code, and
can now be used for proprietary development)

That's the definite YES actually and I can see the team was facing a lot of technical problems in the past. 😃

Since user can perform independent changes to LGPL Qt Library and this binding, the plugin idea is viable in this case, offering the API interface between this binding and the application.

That way, the copyleft effect stops at this "plugin" (depending on its licenses and exceptions), thus perfectly isolating them.

---

(But this is only the case if you exclusively access Qt through this binding, I can't speak for cases in which you directly access Qt, such as when using certain Qt QML Modules for example, which might itself be under GPL or some other license)

Understood. Don't worry about it. It's every developer's duty to read the spec before use.

---

(The license situation for this is a bit more complicate, because it could probably match both definitions "work that uses the library" as well as "work based on the library" and it would greatly depend on the "nature" of this library e.g. what the library does, how it's intended to work and what code it imports. The safest option would probably to open source it under LGPL)

I would very likely to roll model Linux kernel "GPLv2 isolation" style between the user-space and kernel-space: (https://elixir.bootlin.com/linux/v5.0-rc1/source/COPYING) with specifically the isolation exception for user syscall headers (https://elixir.bootlin.com/linux/v5.0-rc1/source/LICENSES/exceptions/Linux-syscall-note). Analogue to this "plugin", it is the "syscall headers" in the Linux kernel case.

If GPLv2 can be isolated that way, I strongly believe there shouldn't be a problem for LGPL. However, I foresee doing it needs Qt team written approval.

---

As for whether to place the plugin here or separate repository, we might need to discuss in the future once a prototype is out. Once the exploration green light is up, I'll produce the prototype that is backward compatible to this repository.

For now, it's too much talking. Time to work on the research, get hands dirty, and have a coffee with my lawyer friend.

---

Thanks for the great insights! I got my answer. Let me know what else you need for X-referencing. I'm ready to close the ticket.

[therecipe]

As for whether to place the plugin here or separate repository, we might need to discuss in the future once a prototype is out. Once the exploration green light is up, I'll produce the prototype that is backward compatible to this repository.

Sounds good, feel free to send a PR whenever you like.
But out of curiosity, which functions do you plan to plugin-ize?

I'm ready to close the ticket.

Me too, feel free to close it.

[hollowaykeanho]

Sounds good, feel free to send a PR whenever you like

Noted with ❤️

But out of curiosity, which functions do you plan to plugin-ize?

Likely offline LGPL graphics modules, on amd64 debian machine first. The first objective is to investigate and to establish a sensible development discipline/process. I'll notify you in a separate issue(s).

Me too, feel free to close it.

Closing ticket.