Huh... I saw your document and you do point up some interesting things. Yeah, I don't think we have a good standard nowadays to point up licenses when the package itself is a monolith that includes its own dependencies in it. Now that I think of it, some other packages probably have a similar issue, like Babashka (since we distribute the uberjar, not compile from source).

But also, IANAL, if all dependencies are compatible with the license of the project itself so the whole project ends up with the license of the most restrictive license. If some of the licenses is incompatible, well, this is a problem of the project and theoretically you can't use it in a legal way.

From the list of licenses you put:

• Apache-2.0
• GPL-2.0-or-later with Classpath-exception-2.0.
• LGPL-2.1-or-later
• LGPL-3.0-or-later
• BSD-3-Clause
• ISC
• MIT
• OFL-1.1

LGPL should be compatible with GPL, and or later should be compatible with later versions, so for the whole GPL part gpl3Plus probably is sufficient. BSD, ISC, MIT are all compatible with GPL too. I don't know OFL-1.1 though, but I just assume it is non-copyleft license so should be fine.

The Apache 2.0 and GPL 3.0 license seems to be compatible (https://www.apache.org/licenses/GPL-compatibility.html), but in one way only. That is, GPL 3.0. So the whole result as a whole should be also licensed as GPL 3.0 I think, and in the end I think the license is gpl3Plus.

But as I said, IANAL.

Huh... I saw your document and you do point up some interesting things. Yeah, I don't think we have a good standard nowadays to point up licenses when the package itself is a monolith that includes its own dependencies in it. Now that I think of it, some other packages probably have a similar issue, like Babashka (since we distribute the uberjar, not compile from source).

Thank you! By all means, everybody criticize my proposal I invite you to.

But also, IANAL, if all dependencies are compatible with the license of the project itself so the whole project ends up with the license of the most restrictive license. If some of the licenses is incompatible, well, this is a problem of the project and theoretically you can't use it in a legal way.

I respectfully disagree because my understanding of the rules when it comes to combined works in this context is that you can link (for some definition of link) a library under LGPL (respectively classpath exception'd) with a program, and that program is allowed to be anything while the library stays protected. In fact that's the reason the LGPL exists as opposed to the GPL. So different pieces of a project can be covered by different copyleft and non-copyleft licenses.

In other words and using a source that's not a court but more authoritative than me:

However, a larger work using the licensed work through interfaces provided by the licensed work may be distributed under different terms and without source code for the larger work.

And to me it seems like the GPL'd pieces of the project (which I enumerated in the doc) are properly isolated from the rest of the project enough so that the combined work does not need to be GPL'd thanks to the linking exceptions. It could be GPL'd since Apache is non-copyleft and since your citation seems to indicate that, but it doesn't need to. This is also the apparent position of upstream, so if anything we should reflect that.

LGPL should be compatible with GPL, and or later should be compatible with later versions, so for the whole GPL part gpl3Plus probably is sufficient. BSD, ISC, MIT are all compatible with GPL too. I don't know OFL-1.1 though, but I just assume it is non-copyleft license so should be fine.

The Apache 2.0 and GPL 3.0 license seems to be compatible (https://www.apache.org/licenses/GPL-compatibility.html), but in one way only. That is, GPL 3.0. So the whole result as a whole should be also licensed as GPL 3.0 I think, and in the end I think the license is gpl3Plus.

No disagreement there. OFL covers a font-icon set hybrid according to upstream so again, each piece its license.

But as I said, IANAL.

same

This is their COPYING file https://github.com/MultiMC/MultiMC5/blob/develop/COPYING.md. Please take a look at this instead of doing it yourself. If it is not correct please contact upstream and ask them for clarification instead of assuming.

This is their COPYING file https://github.com/MultiMC/MultiMC5/blob/develop/COPYING.md. Please take a look at this instead of doing it yourself. If it is not correct please contact upstream and ask them for clarification instead of assuming.

I redid the PR while sticking strictly to COPYING.md. I don't believe I need clarification from upstream.

I don't want to start to much bikesheeding but we should add a comment here I think. Maybe with a link to the license file? So many licenses look suspicious and if someone looks at this in the future they have a point of reference.

That's reasonable. Although this raises the issue that the link is to the develop branch, not the current release. On that note, the current release has a gpl2classpath component in it (pack200) but the next one won't have any. (also if #110439 goes in)

I respectfully disagree because my understanding of the rules when it comes to combined works in this context is that you can link (for some definition of link) a library under LGPL (respectively classpath exception'd) with a program, and that program is allowed to be anything while the library stays protected. In fact that's the reason the LGPL exists as opposed to the GPL. So different pieces of a project can be covered by different copyleft and non-copyleft licenses.

Not authoritative source, but AFAIK linking GPL with LGPL turns everything in GPL: https://softwareengineering.stackexchange.com/a/342158

And to me it seems like the GPL'd pieces of the project (which I enumerated in the doc) are properly isolated from the rest of the project enough so that the combined work does not need to be GPL'd thanks to the linking exceptions.

Huh... Ok, this kinda makes sense. Traditionally GPL code would infect LGPL code, but since the GPL part have the linking exception maybe this isn't true. I still think that LGPL parts would needs to be licensed as a GPL with linking exception, but maybe I am reading it too much.

Rebased and adapted to current MMC version in master.

I marked this as stale due to inactivity. → More info