Congratulations on the progress. If I may ask, I'm curious what considerations have motivated your choice of licence (especially since pushover licences seem extremely popular with all kinds of different Rust projects, as opposed to copyleft).
Copyleft doesn't work well with Rust's ecosystem of many small crates and heavy reliance on libraries alongside static linking.
If one library be GPLv2 and the other GPLv3 they couldn't be used together in one project. LGPL solves nothing because it's all statically linked anyway. And yes, one could licence under both under the user's choice but then GPLv4 comes out and the process repeats itself, and yes one could use GPLv2+ but people aren't exactly willing to licence under a licence that doesn't yet exist and put blind faith into whoever writes it.
Using anything but a permissive licence is a good way to ensure no one will lose your library and someone will just re-implement it under a permissive licence.
C is a completely different landscape. Libraries are larger and the wheel is re-invented more often and most of all dynamic linking is used a lot so the LGPL solves a lot.
Correct me if I'm wrong, but I think all of these are solved problems.
LGPL should only pose a problem if you explicitly want your program to be used with non-free software. And then only if said non-free software doesn't give you a way to rebuild it yourself, should you want to modify the LGPL program. (So not a problem for open-core or public-source projects, either.)
If, for some reason, you insist on allowing static linking for all the projects, I think the MPL allows this. (People often seem to think of the LGPL, but it's not the only weak-copyleft licence around.)
Otherwise, when releasing your project under GPLv3+, you don't have to put blind faith into the FSF; you can designate a proxy which will decide whether the new version should be allowed for your project or not. This proxy can be yourself, or it can be a different organisation you choose to trust. Plus, I'm pretty sure the GPL allows you to make linking exceptions of your liking.
> LGPL should only pose a problem if you explicitly want your program to be used with non-free software. And then only if said non-free software doesn't give you a way to rebuild it yourself, should you want to modify the LGPL program. (So not a problem for open-core or public-source projects, either.)
No, just if you want it to be used with anything that isn't that exact same GPL licence.
> Otherwise, when releasing your project under GPLv3+, you don't have to put blind faith into the FSF; you can designate a proxy which will decide whether the new version should be allowed for your project or not. This proxy can be yourself, or it can be a different organisation you choose to trust. Plus, I'm pretty sure the GPL allows you to make linking exceptions of your liking.
That's the same as just licencing under the GPLv3 and later retroactively deciding to also give the GPLv4 option when liking that licence. The issue is, what if you don't? Then your code can't be combined with any GPLv4 library.
The simple reality is that crates that have incompatible licences, and GPLv2 and GPLv3 are incompatible, cannot be used together in one distributed project without committing copyright infringement. The thing with MIT is that it's compatible with about every single licence out there.
> No, just if you want it to be used with anything that isn't that exact same GPL licence.
How so? The LGPL only demands the four freedoms for the program it covers, not for the entire project. As long as the user is free to use their own modified version of the LGPL program (by dynamic linking or being able to recompile) and share it with others, the licence should be satisfied, so even if your project as a whole is read-only or has a pushover licence, no?
> That's the same as just licencing under the GPLv3 and later retroactively deciding to also give the GPLv4 option when liking that licence.
It's practically the same if you own all of the code. Which, if you happen to run a public project which ends up accepting a lot of contributions, you won't.
> The issue is, what if you don't? Then your code can't be combined with any GPLv4 library.
Fair enough, but I don't think this problem can be solved. If you want any licensing changes to happen without explicit consent from every single contributor, you have to put a bit of blind trust in someone. My point was that in the case of the GPL, it doesn't have to be only the FSF.
Not in particular, but it's pretty common for permissively licensed projects to complain about companies complying with their license instead of what they imagine the license to be, then relicensing to a proprietary or copyleft license (e.g. Elasticsearch for a high-profile case but there are many others). This lead to some people disliking permissive licenses.
Personally I dislike them because they don't preserve end-user freedom, I prefer the MPL. But if someone wants to donate their work to for-profit companies that's their choice.
'Pushover licence' is a licence which may grant freedom, but doesn't care to protect it. One may modify software under a pushover licence and release their modifications as non-free software. Another, more common name is 'permissive licence'.
