On Thu, Feb 03, 2022 at 12:29:11PM +0100, Krzysztof Kozlowski wrote:
On Thu, 3 Feb 2022 at 12:08, Dan Carpenter dan.carpenter@oracle.com wrote:
This does not look like compliant with GPL-2.0. You cannot call a license GPL-2.0 and restrict it with some other provisions.
That's the MIT license. It's not the GPL-2.0 license but it is compliant.
It's compliant when included as "OR" for example in SPDX tag. The current solution - SPDX and MIT license text - is not the proper way to describe this. Otherwise one could argue that both licenses apply at the same time and one has to fulfill both of them, which is ridiculous. There is a SPDX tag for the proper case - GPL or MIT.
You're saying a bunch of different things.
We both agree that the SPDX text is confusing because it says GPL-2.0+ but it has the text from the MIT license.
"This does not look like compliant with GPL-2.0."
Wrong. The MIT license is compatible with the GPL-2.0.
"You cannot call a license GPL-2.0 and restrict it with some other provisions."
Wrong. The MIT license just says you have to include the No Warranty text. The GPL has it's own list of requirements. But you can combine MIT and GPL code and easily comply with both requirements. That's what "compatible" means in this context.
In the kernel we have MIT licensed code which is dual licensed. This means that someone can take that driver and release it as closed source software if they want.
// SPDX-License-Identifier: GPL-2.0 OR MIT
Then we also have code which was originally MIT licensed but now you have to comply with the GPL as well.
// SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT
These examples were cut and paste from Documentation/process/license-rules.rst
regards, dan carpenter