GPL table

[rhn]

Hi!

Thanks for the awesome license checker, this is something I dearly feel is missing in the Rust ecosystem. The way crates.io is structured is suited for permissive licenses, but not so much for respecting copyleft licenses. Here's a GPL table that will hopefully help with that.

The one resource I used is https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility, usage explained in the comments. I limited myself to diligently copying the entries, without going into "or later". The second commit may cause somewhat misleading situations, as there's no way to represent a license upgrade at the moment. I thought it's still useful to have.

[Nemo157]

I believe the main point of this compatibility checking is to say

If I license my crate under license A and pull in a dependency under license B, does license B place an increased burden on users to comply with the combined licensing constraints?

Under that check having a GPL-3.0-only licensed crate and adding a BSD-3-Clause licensed dependency is ok, you already have terms requiring attribution and license redistribution from GPL so extending that to include the attribution and license redistribution from the BSD license doesn't increase users burden.

Having an LGPL-3.0-only licensed crate and adding a GPL-3.0-only licensed dependency would not be ok, you are now going to be placing a new burden on users that were dynamically linking your library to release their source code under the GPL-3.0-only license.

That interpretation I believe rules out the second commit.

The first commit I'm less sure about, they don't explain what they mean by "use a library" in that table. Because Rust dependencies are statically linked I believe for the GPL licenses they are really covered under the "I want to copy code under" section, "I want to use a library under" is presumably related to the linking exception from LGPL which only applies when users of the binary can easily replace library with an alternative version.

[rhn]

I believe the main point of this compatibility checking is to say

If I license my crate under license A and pull in a dependency under license B, does license B place an increased burden on users to comply with the combined licensing constraints?

This interpretation is valuable to library authors, but it's incomplete to application authors, who are more likely just to care whether distribution of the software resulting from combining various licenses is allowed, no matter what additional burden is involved. I do think there's space for both outcomes to be presented to the user in lichking.

However, currently there's no way to express the difference, so I agree that the second commit needs some additional tooling to be acceptable.

As for the second, commit, I think it's quite clear that any kind of linking at compile time qualifies as using the library:

“Use a library” means that you're not copying any source directly, but instead interacting with it through linking, importing, or other typical mechanisms that bind the sources together when you compile or run the code.

http://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic , where the FSF is likely taking the strictest possible stance, confirms this:

Does the GPL have different requirements for statically vs dynamically linked modules with a covered work?

No.

I think this makes it clear that the first commit is good, at least in the sense that it's not too lax.

EDIT: Should I then limit the contribution to the first commit only?

[Nemo157]

This interpretation is valuable to library authors, but it's incomplete to application authors [...]

This is a good point. I'll try and find some time this week to work on #57 and see if I can come up with a nice way to present this difference. (I'll probably open another ticket during that to better support application authors, we can even automatically detect whether there is a binary associated with the current crate to determine what it does by default.)

I think this makes it clear that the first commit is good, at least in the sense that it's not too lax.

I think the more relevant FAQ entry is this: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic. That makes it clear that while the requirements the LGPL licenses place on you don't change, your choice of linking changes how you must respond to those requirements.

I'm going to have to spend some time thinking about how Rust packages are used together and how that really interacts with the linking exception.

[rhn]

I think the more relevant FAQ entry is this: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic. That makes it clear that while the requirements the LGPL licenses place on you don't change, your choice of linking changes how you must respond to those requirements.

I think this is already being covered. The object code situation only matters if a non-GPL license project uses LGPL dependencies. My change doesn't allow that, so no changes are needed.

Lichking also allows GPL, which inherently places additional burden (release sources) on any non-GPL library it links with, so linking to LGPL is already covered.

That's for static linking. Dynamic linking is not really any different, because it's only about "if you distribute GPL in any form, you need to provide sources", and that kicks in in both cases.

[Nemo157]

The main case I'm thinking about is "I want to license my code under LGPL-2.1-only" and "I want to (use a library/copy code) under LGPL-3.0-{only,or-later}".

As a non-copyleft application using a library in the above situation I would be keeping that library's usage in a dynamically linked sub-crate so that the bulk of the application code can be proprietary/copy-left-incompatible-OSS licensed. If that library added a new LGPLv3 dependency then that dynamically linked sub-crate would now have to comply with the LGPLv3 restrictions as well as LGPLv2.1 (since you are distributing a statically linked library containing the LGPLv3 dependency).

I don't know whether LGPL-3.0 adds any extra distribution restrictions over LGPLv2.1, and if it does whether they're impactful enough to really make a difference.

(Similarly, having an LGPL-2.1-or-later library add an LGPL-2.1-only dependency will require users of that library to now comply with either LGPLv2.1 or (LGPLv2.1 and LGPLv3) when they could have previously chosen to just comply with LGPLv3).

[rhn]

The main case I'm thinking about is "I want to license my code under LGPL-2.1-only" and "I want to (use a library/copy code) under LGPL-3.0-{only,or-later}".

As a non-copyleft application using a library in the above situation

In that situation, lichking already says that the check is failed. Which is fine, if we assume that we want to avoid additional burden. So if we set aside those situations, we can still add entries from the GPL table when linking doesn't change anything (that would be some combos in the GPL family). I think that would be a good step forward before more difficult situations are tackled.