-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GPL table #55
base: master
Are you sure you want to change the base?
GPL table #55
Conversation
Combinations which were not explicitly listed in the table at https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility are skipped, e.g. "I want to license my code under GPLv3 only". Fields where the upgrade would change the license to GPLv3 are skipped.
This implements the ields in the table where the combined work would be licensed differently than the constituents. It still only counts explicit fields in the table, without taking advantage of the fact that what's compatible with Foo is compatible with Foo_or_later.
I believe the main point of this compatibility checking is to say
Under that check having a Having an 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. |
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:
http://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic , where the FSF is likely taking the strictest possible stance, confirms this:
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? |
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 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. |
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. |
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 |
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. |
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.