The MIT license is ‘allowed’. The code in itself is MIT licensed. It's just that, when compiled and linked against fuzzywuzzy, the aggregate work that results must be GPLed.
It's not clear that the aggregate work is allowed to be distributed under the GPL. My legal hypothesis (from having worked with BSD licensed code and noticed how much hassle having many licenses is) is that the extra requirement of repeating the MIT license could be challenged against the "extra restrictions" clause of the GPL. Think of the case of having 500 variant MIT/BSD3-clause/et licenses that CLAIM to mean the same thing and need full reproduction; the cost of having lawyers verify this is substantial, so it is an actual substantial restriction.
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.
The act of linking against a library produces a derivative work of that library. But since APIs are not copyrightable (in europe, at least), the act of using an API does not produce a derivative work, and thus code which uses an API is not bound to any particular license wrt it.
I don’t understand what you mean. You can’t use the API without, in this case, importing it in the python code. That means you bring in a whole copy of the code into your project, or the API wouldn’t work, right?
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.
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?
interesting: given that it may at any time hit that line of GPL'd code, your claim is that the rest of the code can be MIT licensed? i am not a lawyer but that sure seems like a borderline case at best.
The author can licence their source code however they want.
The GPL doesn’t relicense other code either, it’s that the GPL asks you to additionally follow its terms for the whole resulting compiled distribution
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.)
From the FAQ, I don't get why the code has to be GPL licensed. It talks about libraries, "entire combinations", "software modules that link" and "work as a whole".
On your second point: Can't they argue that they implement against an API, which could be provided by non-GPL software as well?
Compatibility with GPL in this case simply means a software distributed in a compatible license like MIT can be combined and distributed under GPL [0].
>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].
Almost. The author can license their contributions with a more permissive license if they want (e.g. individual files can be MIT licensed) but the software as a whole must be licensed under the GPL.
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.
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.