Fuzzywuzzy is not MIT compatible
onerandomusername opened this issue · 9 comments
Description
Fuzzywuzzy is not compatible with an MIT license, even though this project is licensed as such.
However, rapidfuzz is compatible, so if the dependency is changed, there is no longer a violation of licensing.
Interesting -- I had assumed that since the modules weren't linked together, the GPL flow-through behavior didn't apply.
I see now that I was incorrect in this; e.g., per https://opensource.stackexchange.com/a/2148/1130.
I'll have to review my other projects for this -- thanks for bringing it to my attention!
In terms of a replacement, I don't especially like how rapidfuzz requires separate install of a VC++ redistributable on Windows. I think I'll have to either find another package, or just implement my own matcher. Either way, it would make sense to implement in tandem with #207, I think.
fuzzywuzzy commit while still MIT:
https://github.com/seatgeek/fuzzywuzzy/tree/4bf28161f7005f3aa9d4d931455ac55126918df7
Thank you for trying to fix this, btw! I want to use this rather than write my own parser, but the fuzzer that means that I can't with my current project licensing.
- Update docs
- Update tox dependencies matrix (incl. removal of
fuzzywuzzy) and Pythons (add 3.11) - Remove
speedupextra - Remove fuzzywuzzy from requirements files
- Freshen CI Pythons
Yeah, if I'd correctly understood the licensing implications, I never would have pulled fuzzywuzzy in in the first place.
Do I understand correctly that if fuzzywuzzy/python-Levenshtein had been licensed either as (i) LGPL or (ii) GPL+ClassPath, I could have used them and kept sphobjinv as MIT?
Do I understand correctly that if fuzzywuzzy/python-Levenshtein had been licensed either as (i) LGPL or (ii) GPL+ClassPath, I could have used them and kept sphobjinv as MIT?
I have no idea.
v2.2b1 is up on PyPI, with a MIT-compatible version of fuzzywuzzy vendored in and all dependence on current fuzzywuzzy and python-Levenshtein removed. pip install --pre sphobjinv, or pip install sphobjinv==2.2b1 should get it.
I'm pretty confident this resolves the license conflict ... once I've finished updating the docs and have a final v2.2 released, I'll go ahead and yank the rest of the v2 series to discourage further use.
Now that the Levenshtein speedup isn't available, though, I'll be taking a close look at #178 as an alternative speed boost....
I'm pretty confident this resolves the license conflict ... once I've finished updating the docs and have a final v2.2 released, I'll go ahead and yank the rest of the v2 series to discourage further use.
This could break other projects depending on this one, as I recall some issues with pip not being able to install packages within a provided range if all of them are yanked.
For example, someone is looking for any ~2.1.x releases, but all are yanked so pip won't be able to find a package.
That's exactly why I was thinking I'd yank them, to alert at least some users of the license conflict and the need to update their pins. 2.2 should be feature-identical to 2.1, and is a feature superset of 2.0.x, so it should be an easy fix.
Anybody with an open-ended >=2 pin would pick up 2.2 automatically, so non-issue there.
Anybody with a == pin to 2.0.x or 2.1.x would still get that version...yanks don't affect affect version pins... so these users wouldn't get notified by the yanking...they'd have to just happen to notice it...not sure what I can do
Not perfect, but it's the noisiest thing I can think of short of deleting those earlier 2.x versions, which I definitely don't want to do.
But, all that said, maybe that's more than I need to do? I don't really know what the proper response is in this situation, besides modifying the project to avoid the license conflict going forward.