I may take over ownership of a crate that has changed hands once already. The current crate is less efficient than mine - as are all but one (also inactive) ordinal crate I found - and hasn't been touched in a couple years, and I'd love to replace it given it has the obvious name. The current crate owner said they are okay with turning it over, but that crate and its source are under the MPL2.0. My source is under the MIT.
While the source is different and there's probably no license concerns there, are there concerns about putting a new compatible version of the crate under a different license?
Apart from any legal advice, that I cannot give due to not being a qualified lawyer (IANAL), from a user's perspective, I'd rather phase out the "old" library and communicate your alternative implementation as a successor under a different name.
This way the users will not be surprised when and if the entire codebase and the license change (I for one use a .cargo/deny.toml with limited licenses in all my professional projects).
Technically, MIT requires including a copy of the license with the software, and MPL requires including notification how to obtain the source code and the license, so they have different compliance requirements. If someone just updates the dependencies and doesn't re-check the licensing requirements, they could be violating the new license.
In practice, almost nobody seems to care about the requirement to provide a copy of the license. And given that Rust projects can have hundreds of dependencies, this requires tooling to automate anyway.
I could also consider relicensing my code. It’s only had a single release, though about 70 pulls so far. I should look it obvious dual license these two. There’s a lot in common but it’s the differences that are concerning.
The crate I’m looking to take over has the obvious name and I rather replace that one to provide a much faster implementation.
If cargo supported deprecation notifications like nuget and, iirc, npm, id be in favor of what you suggest.
I like the idea of a new name. Maybe crate_ng.
You can probably use a compile error (or warning) for the crate users that tells them this crate is outdated and suggest they use crate_ng. Maybe just a warning for a year, then an error.
Fortunately I’m the only author so that may be an easier course of action. MPL is a bit more copyleft than I personally like, but it’s a weak copyleft.