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@xxxxxxxxxx> 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
