Android OEMs are not in the business of writing kernels, though, and the changes they do are minimal. And their HAL/chipset code -- the thing they might actually care about as IP -- is not governed by the GPL at all, nor is any of the enormous volume of system and userspace code they write.
It's a neat initiative and might yield something interesting, but if the Linux kernel was replaced by Fuscia the ramifications are seemingly very minor. Android's many issues have never been at the kernel level.
Qualcomm has no obligation to GPL their kernel drivers. Nor does nvidia, or any other KLM maker. This has never demanded that kernel drivers be open sourced. That's why it's impossible to make a runnable AOSP image for many devices.
Vendors still make generally minor changes to the kernel, but these are not unique or special or some competitive edge. They've just nuisance necessities.
It's way more grey than that. Nvidia claims that their driver doesn't need to be opened because since it's A) from a codebase that existed prior to the Linux port, and B) doesn't actually import any Linux code or symbols (that's left to a dual licensed shim layer), that in a legal sense their driver isn't 'derived from' the Linux kernel and isn't subject to the viral parts of the GPL. And, all of this is the greyest of grey area. Towards that end, Nvidia has been committing to Nouveau lately for Tegra chips because I think they realize how precarious their legal situation is for chips essientially designed to run Linux.
That reasoning doesn't apply to most kernel drivers, and those vendors are just openly in conflict with the GPL.
Literally any driver that has a piece that runs in interrupt context has to have (in part) a kernel mode driver under Linux.
On top of that, GPUs generally have to have a kernel component, even under systems that put as much as possible under user mode like sel4, because they have their own MMUs that can subvert kernel integrity.
Again, yes there are drivers running in the kernel space, yes they are mostly GPL, no Google isn't re-writing them into Binderized HALs, they can stay as Passthrough HALs.
Nothing of that prevents that all new drivers, except for the ones marked as legacy, are required to be Binderized.
The kernel code of a driver from OEMs allergic to GPL, is hardly different from a signal handler, implementing the minimal set of kernel code and deferring everything else to userspace.
Ah appealing to authority as last argument, naturally any kind of opinion and knowledge of what I might have as Android developer, or former professional experience in systems programming is worthless.
More that I recognized a position that comes from a cursory understanding of the situation. About the level I'd expect from having taken a few classes on it, but lacks true experience in the domain. One of those "in theory, theory and practice are the same. In practice, they're not" sort of situations. You've taken those ideas to conclusions that could have been valid, but the industry took other options.
Now, as someone who has spent a decade in that domain, I'm down to continue having a conversation about it and helping overcome a few of those hurdles, but you need to be willing to hear something that isn't your own conclusions.
Linux has countless LKMs (modules that run in the kernel, but are not -- broadly -- bound by the GPL). Many, many are closed-source and proprietary. Others aren't because they don't have to be.
You hinted that this transgresses the GPL, and there are those that argue that virtually anything transgresses the GPL. But a lot of very large corporations say otherwise, and there have been zero successful challenges against it.
Comments
Well a change of the kernel's license from GPLv2 to BSD is certainly a change. I'm sure the OEMs think that gains them something.
Android OEMs are not in the business of writing kernels, though, and the changes they do are minimal. And their HAL/chipset code -- the thing they might actually care about as IP -- is not governed by the GPL at all, nor is any of the enormous volume of system and userspace code they write.
It's a neat initiative and might yield something interesting, but if the Linux kernel was replaced by Fuscia the ramifications are seemingly very minor. Android's many issues have never been at the kernel level.
The components of their HAL/chipset code in the kernel are most of the time governed by the GPL. We can take some examples apart of need be.
After Project Treble that only applies to the legacy HAL code.
Even fully after Treble, there are absolutely still kernel drivers.
Qualcomm has no obligation to GPL their kernel drivers. Nor does nvidia, or any other KLM maker. This has never demanded that kernel drivers be open sourced. That's why it's impossible to make a runnable AOSP image for many devices.
Vendors still make generally minor changes to the kernel, but these are not unique or special or some competitive edge. They've just nuisance necessities.
It's way more grey than that. Nvidia claims that their driver doesn't need to be opened because since it's A) from a codebase that existed prior to the Linux port, and B) doesn't actually import any Linux code or symbols (that's left to a dual licensed shim layer), that in a legal sense their driver isn't 'derived from' the Linux kernel and isn't subject to the viral parts of the GPL. And, all of this is the greyest of grey area. Towards that end, Nvidia has been committing to Nouveau lately for Tegra chips because I think they realize how precarious their legal situation is for chips essientially designed to run Linux.
That reasoning doesn't apply to most kernel drivers, and those vendors are just openly in conflict with the GPL.
Sure there are, they are known as "legacy HALs" on Project Treble documentation.
Literally any driver that has a piece that runs in interrupt context has to have (in part) a kernel mode driver under Linux.
On top of that, GPUs generally have to have a kernel component, even under systems that put as much as possible under user mode like sel4, because they have their own MMUs that can subvert kernel integrity.
Again, yes there are drivers running in the kernel space, yes they are mostly GPL, no Google isn't re-writing them into Binderized HALs, they can stay as Passthrough HALs.
Nothing of that prevents that all new drivers, except for the ones marked as legacy, are required to be Binderized.
The kernel code of a driver from OEMs allergic to GPL, is hardly different from a signal handler, implementing the minimal set of kernel code and deferring everything else to userspace.
Sort of...
I'm going to go out on a limb here and guess that you don't actually write kernel drivers like I do professionally.
Ah appealing to authority as last argument, naturally any kind of opinion and knowledge of what I might have as Android developer, or former professional experience in systems programming is worthless.
Nice.
More that I recognized a position that comes from a cursory understanding of the situation. About the level I'd expect from having taken a few classes on it, but lacks true experience in the domain. One of those "in theory, theory and practice are the same. In practice, they're not" sort of situations. You've taken those ideas to conclusions that could have been valid, but the industry took other options.
Now, as someone who has spent a decade in that domain, I'm down to continue having a conversation about it and helping overcome a few of those hurdles, but you need to be willing to hear something that isn't your own conclusions.
Just like you need to be willing to accept that GPL won't stay forever on Android, but you are right I don't have a clue.
As for systems programming experience, you would be surprised, but I am not here to justify myself with appeals to authority.
Linux has countless LKMs (modules that run in the kernel, but are not -- broadly -- bound by the GPL). Many, many are closed-source and proprietary. Others aren't because they don't have to be.
You hinted that this transgresses the GPL, and there are those that argue that virtually anything transgresses the GPL. But a lot of very large corporations say otherwise, and there have been zero successful challenges against it.