change license to MIT?

[StefanKarpinski]

I was looking for LGPL packages, suspecting that there should not be many since for a Julia package there's no such thing as "linking" making LGPL equivalent to GPL. I found this package, which appears to be LGPL because it's a wrapper around an LGPL library (which is dynamically linked, so that makes sense). Wrapper code need not have the same license as the wrapped library, so this package could and arguably should be MIT licensed. As it stands, whereas Qt can be used with/by non-open source software so long as modifications to Qt are released in accordance with the LGPL, QML.jl cannot be used with/by non-open source software, which I don't think was the intention. Since there are still relatively few contributors, getting permission for a license change should be tractable.

[barche]

Yes, I made this LGPL because Qt is LGPL. SO how should I change this? Just tag all contributors in this issue? I guess it's best to do it before the Qt 6 release.

[StefanKarpinski]

Yes, if everyone indicates their assent here, then you can change the license.

[barche]

Dear QML contributors,

Following Stefan's suggestion above, I would like to change the license of QML.jl from LGPL to MIT, in line with almost all other Julia packages. The original choice for LGPL was based on the fact that Qt itself is LGPL licensed, and in fact both the C++ code and the Julia code were in the same repository when this package was created.

For a more fundamental rationale on why MIT is a good choice for a Julia package I recommend Stefan's post here: https://discourse.julialang.org/t/package-license/7109/15

To indicate your agreement or disagreement you can simply reply on this issue, or use the react +1/-1 buttons.

Contributors according to Github: @bramtayl @treygreer @LeMinaw @ufechner @aminya @mkitti @SimonDanisch @Hugo-Trentesaux @giordano @NHDaly @stemann @staticfloat @samuelpowell

[mkitti]

👍 I concur with the license change and assign the copyright of my contributions to Bart Jenssens, @barche.

[staticfloat]

I agree.

[Hugo-Trentesaux]

For my projects, I prefer AGPL, but for others, I'm ok to MIT ^^
(see https://discourse.julialang.org/t/package-license/7109/16)

[bramtayl]

I agree

[ufechner7]

Perhaps this can be closed now that 0.8 is released?

[barche]

The license has been changed in release 0.8.

[ShalokShalom]

Is it required by the user to comply with the LGPL in any capacity?

Since when, we should make the user aware about that.
Do we need to add a copy of the LGPL, as an example?

As the Qt code itself is still LGPL 3 licensed.
I understand, that this does not affect the wrapper code, but the used Qt code would still need to have at least the LGPL license attached, yes?

https://discourse.julialang.org/t/ann-qml-jl-v0-8/104328/11

[mkitti]

If the user redistributes their Julia depot (default ~/.julia), then they may come under the terms of the LGPL.

From QML.jl, I think one of the first places in the dependency tree that one encounters the LGPL is from a Qt6Declarative_jll.jl artifact:
https://github.com/JuliaBinaryWrappers/Qt6Declarative_jll.jl/blob/de21114446a4801789a7d1452e0cf469cf45bf1e/Artifacts.toml#L186-L194

~/.julia/artifacts/5ec56e0e1b25eaaa5a9562609d54195b360a0348/share$ tree
.
└── licenses
    └── Qt6Declarative
        └── LGPL-3.0-only.txt

2 directories, 1 file

If you redistribute this artifact, then you you are bound by the terms of the LGPL.

Disclaimer: I am not a lawyer.

[ShalokShalom]

At which place in the documentation should we add this?

I suggest at least on the bottom of the README.
I could prepare a PR.

[barche]

There is no need to add any documentation about this, the licenses themselves are the documentation about the license, the fact that each JLL needs to include the appropriate license is already documented: https://docs.binarybuilder.org/stable/jll/#Anatomy-of-a-JLL-package

[ShalokShalom]

But do they know, that Qt is LGPL licensed? I think like a hint about that would make sense.
As most of our ecosystem is not licensed like that, and a heads-up couldn't hurt. 🙂

[giordano]

If you redistribute this artifact, then you you are bound by the terms of the LGPL.

The LGPL is not viral.

But do they know, that Qt is LGPL licensed?

Who's "they"?

[bilderbuchi]

If you redistribute this artifact, then you you are bound by the terms of the LGPL.

The LGPL is not viral.

This is kinda orthogonal. "Not viral" does not mean that you are not bound by the terms of the LGPL (for the thing you use) - you still need to observe the terms.

[bilderbuchi]

the fact that each JLL needs to include the appropriate license is already documented:

On that page I only find mention that the license needs to be in the shipped tarball...that's not exactly well-discoverable by a user, don't you think?

[ShalokShalom]

Who's "they"?

The users.

@bilderbuchi I value the approach, to streamline this via the linked implementation attempt of automatizing metadata in the Project.toml

This would solve this topic, yeah?

[giordano]

"Not viral" does not mean that you are not bound by the terms of the LGPL (for the thing you use) - you still need to observe the terms.

That's quite obvious, but I was pointing out that LGPL doesn't affect the entire distribution, contrary to GPL.

[barche]

There are basically 3 possible types of users:

1. End-users: build a GUI for themselves. That use case is automatically within the bounds of both LGPL and MIT, so they are fine without extra documentation
2. Builders of open-source Julia packages, licensed under the standard MIT license as is customary in our ecosystem: they are also automatically compliant with the license terms, and don't need extra documentation
3. Commercial entities that think they need to close off their code as part of their business model: the burden of figuring out how to comply to licensing terms and where and what they have to pay to be compliant is entirely on them and their legal team, so they don't need extra documentation.

Given the amount of disinformation that already does the rounds regarding the Qt license, I think adding any extra mention of the licensing apart from what is already mentioned in the license terms as we distribute them now would only give rise to further confusion, so I am opposed to adding any extra notice about this at all.

[ShalokShalom]

@giordano

That's quite obvious, but I was pointing out that LGPL doesn't affect the entire distribution, contrary to GPL.

Stefan mentioned above, that all Julia code is basically turning a LGPL into GPL, as there is no linking.

Or am I confusing something?

@barche

There are basically 3 possible types of users:

I would already fall not within that three standard cases, at least as far as I can tell.

I am interested into building apps that are intended to be used by the KDE folks¹,
and to license that apps under the MPL-2.0. How would I be required to comply?

This all seems very daunting, so I welcome the automated approach, that I see promised by JuliaLang/Pkg.jl#1070

---

¹ without using their libs, as we have no bindings to them yet

[barche]

The problem Stefan mentioned was due to the fact that QML.jl itself was LGPL licensed. This is fixed as of version 0.8. Regarding your use case: as far as I understand MPL-2.0 is also Open Source, so you should be perfectly fine. Remember that you are just using the Qt libraries, not modifying them, so especially in an open source context there is no danger whatsoever. MIT on QML.jl allows you to use MPL-2.0 for your own code, and the Julia package manager will install all dependencies including Qt itself along with their license.