Apache 2.0 License is incompatible with GPL v2

[dralley]

Describe the bug

It appears that this library used to be licensed as MIT and eventually switched to Apache 2.0 for patent protections: #175

This is understandable but unfortunate because the Apache 2.0 license is not compatible with the GPL v2 license (at least according to the FSF, opinions on this differ).

The standard workaround for this (very common in the Rust community) is to license projects as MIT OR Apache 2.0, which means that contributions invoke the Apache 2.0 protections but downstream users can choose which license they want to accept the code under.

It would be excellent if aiohttp followed this strategy.

To Reproduce

N/A

Expected behavior

N/A

Logs/tracebacks

N/A

Python Version

N/A

aiohttp Version

$ python -m pip show aiohttp

multidict Version

$ python -m pip show multidict

yarl Version

$ python -m pip show yarl

OS

N/A

Related component

Server

Additional context

No response

Code of Conduct

• I agree to follow the aio-libs Code of Conduct

[asvetlov]

The switch happened in 2014, when aiohttp was in early beta.
Since that time I don't recall any license blame. Seems like people are satisfied with the status quo.

IIRC Apache 2.0 is compatible with GPLv3. GPLv3 is not compatible with older GPLv2.
Why should we care?
Why is GPLv2 support so important?
Should GPLv1 be supported?
Is Python PSF license considered GPLv2 compatible? Why?

I'm not a lawyer though.

[dralley]

Frankly most people don't pay much attention to licensing issues 🤷

re: GPLv2, I don't have any statistics but I honestly expect it's more widespread than GPLv3. As far as I can tell the PSF license is compatible.

[Dreamsorcerer]

re: GPLv2, I don't have any statistics but I honestly expect it's more widespread than GPLv3.

I was under the impression the majority of projects were GPLv2+ or GPLv3. The Linux kernel being the only notable exception that comes to mind as GPLv2 only.