Is the GPL actually viral across dynamic linking?

Posted Nov 16, 2024 17:44 UTC (Sat) by viro (subscriber, #7872)
In reply to: Is the GPL actually viral across dynamic linking? by Baughn
Parent article: Two approaches to tightening restrictions on loadable modules

GPLv3 is incompatible with GPLv2. Kernel is under GPLv2, _NOT_ GPLv2-or-later, and that's not going to change. GPLv3 is not different from e.g. CDDL in that respect.

And exports are really, really not something one could describe as an API - it's a huge pile of random functions and variables some module had found convenient to call at one time or another. It's more than one order of magnitude past anything sane and it had been for decades. Ironically, the same crowd that comes a-whining about stable in-kernel ABIs is going to scream bloody murder if somebody tries to reduce that pile of shit to something that might be described as an interface. For that to be even remotely similar to relationship with a dynamically linked library we'd need to stop exposing the internals to such extent; it's far more than any sane library would and that stretches the comparison way past the breaking point.

Licensing or not, we really need to get the exports surface into a saner shape; namespaced exports are interesting precisely because they allow some moves in that direction.

Is the GPL actually viral across dynamic linking?

Posted Nov 16, 2024 18:15 UTC (Sat) by quotemstr (subscriber, #45331) [Link]

Of course the set of exported symbols is an API. That the API exposes too many internal details and is more evolved than designed doesn't make it not an API. Out of tree modules exist. Breaking them causes real users real annoyance.

One should design programming interfaces with an eye towards how the ecosystem will use them. Declaring that something isn't an interface or an API when it looks like an API, walks like an API, and quacks like an API just makes it harder to fix the warts in the API surface. Doing so denies problems instead of fixing them.

Blacklisting an out of tree module *by name* in the core kernel crosses the line between encouraging collaborative development and outright user hostility. Wanting to do so is a signal that some user have unmet needs. Going out of the way to make it harder to satisfy these needs isn't the way. If I were packaging a distro kernel, I'd patch out the blacklist.