this is nice - it looks like it's linked against at least one GPL lib (fuzzywuzzy) though, so the MIT license almost certainly isn't allowed. looks like there's only one usage though, the other is an unused import, so may be easy to change
https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
The problem for the author in this case is that a) writing their code against a GPL'd library constitutes creating a derivative work, and b) putting it on GitHub is distribution.
> the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL.
The application is a ‘software module’ licensed under the MIT license (a ‘GPL compatible license’). When you link that application against the GPL'd library, the resultant ‘work as a whole’ must be provided under the terms of the GPL.
(Since the MIT license allows relicensing, and the GPL does not contradict any of the terms of the MIT license, this is legal. If the MIT license did not allow relicensing, or if it contradicted some term of the GPL, the OP's application would still be legally licensed under the MIT license. It would just be illegal to link it against its GPL'd dependency.)
Licenses are freaking confusing :) but I think folks are correct to point this out.
My understanding is that all of the new files the author wrote can individuals be licensed MIT, but unfortunately the work as a whole should be GPL.
On your second point: Can't they argue that they implement against an API, which could be provided by non-GPL software as well?
>On your second point: Can't they argue that they implement against an API, which could be provided by non-GPL software as well?
I don't think that is reasonable. A GPL program is specifically named in requirements.txt and imported. It's essentially the same as dynamic linking, that is no more than naming a program and using it's API. If this argument was valid one could also argue it's possible to modify a dynamically linked binary's rpath (can be easily done with patchelf on GNU/linux) from a GPL library to a non-GPL one so dynamically linking a library would never require you to do abide to it's license, which is obviously untrue [1].
[0]http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
[1]http://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
I’m not at all convinced that a court would agree, particularly when the effect on the code is fairly insubstantial.
I guess it boils down to whether the LICENSE file is meant to apply to the code in that repo or the software it produces when built. I would expect the latter, but I guess it's a bit ambiguous since we're having this discussion.
The line between an API and code describing and documenting that API is quite fine. See Google vs Oracle.
Google v oracle happened in the us. I explicitly qualified with ‘in europe’. That lawsuit would never have flown in the first place. Oracle's position was specifically that they held the copyright of the java stdlib APIs, which copyright was infringed upon by google.
> code describing and documenting that API
I'm not sure what you mean by that, can you clarify?
So, my understanding is the author’s new files that use the GPL licensed library can individually be licensed MIT, but the work as a whole must the GPL.
GNU believes that the lax licenses (MIT, advertising clause free BSD) are "compatible with GPL" because the GPL requires attribution and the licenses can be considered a form of attribution.
The actual status of this has, to the best of my knowledge, not been tested in court. Because this is a claim from the group that wants to add restrictions (the GPL side) and they generally want to be able to take BSD code and apply extra restrictions to it, it's not clear it's a large risk in practice.
In Python, it's literally just a line of text, an instruction to import something. If that thing doesn't exist, too bad. The user is responsible for supplying it, not the Python code.