Messages in this thread | | | Subject | Re: [RFC PATCH 6/9] memory: apple: Add apple-mcc driver to manage MCC perf in Apple SoCs | From | Hector Martin <> | Date | Thu, 14 Oct 2021 17:31:25 +0900 |
| |
On 14/10/2021 17.04, Krzysztof Kozlowski wrote: >> It is; only modules with a GPL-compatible MODULE_LICENSE get to use >> symbols exported via EXPORT_SYMBOL_GPL. > > Although there might be such correlation but it's not a rule. You can > have a GPL module exporting symbols without GPL requirement > (EXPORT_SYMBOLS). You can have a GPL+MIT module exporting symbols as > GPL. Obviously you cannot have a non-GPL module, as we do not accept > these and there is no such choice.
What I mean is that modules can only import GPL symbols if they themselves are GPL compatible. What I didn't know is that "Dual MIT/GPL" is a valid string for MODULE_LICENSE to qualify as such.
>> See kernel/module.c for the symbol lookup logic and >> include/linux/license.h for the logic to check the string (seems like >> "Dual MIT/GPL" is explicitly whitelisted there). > > Not related to export symbol. It is used for determining the tainted > kernel via other licenses. >
Not just that; that module taint is used as a filter so that non-GPL-compatible modules are technically prevented from resolving EXPORT_SYMBOL_GPL symbols.
>> Of course, this is a futile effort, as ~every time I see a proprietary >> module in some embedded device, it either falsely declares itself to be >> GPL, or they have a shim module that re-exports GPL symbols as non-GPL. >> > > This is being removed soon (or already).
? Good luck getting proprietary embedded vendors to start following licenses... :)
-- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub
| |