Funny because that's exactly how most commercial Linux-based products work, including and especially Android smartphones. In my opinion, tolerating TiVo-ization was a major and possibly fatal misstep for GPL enforcement. What is a firmware blob, if not a derived work?
It stems from a "nerdy" interpretation of "linking" that considers as relevant the fact that the monolithic proprietary blob (encrypted, protected, unmodifiable) has some sort of internal interface that mirrors the way a user might use a hypothetical free version of the product (running proprietary processes on a free kernel/userland). But it ignores the fact that the user cannot in practice disentangle the product in any way. It is the user experience that should legally be the deciding factor.
I realize this may be a controversial stance, but consider - what if I released a proprietary and closed source desktop application that bundled into its binary a copy of the Linux kernel? Are the specifics of how it interacts internally with this code really relevant? Is this really a different situation than code that runs bare metal?
If you wrote the firmware on your own before, and it works on multiple operating systems, and you didn't refer to Linux to use it... I don't understand how one would think it's a "derived work". How does it "derive" from Linux?
I was perhaps unclear. I meant a firmware blob in the sense of an OS image that includes Linux, such as might be downloaded as an update to your smartphone.
Can you delete the proprietary software, and if so does the Linux still run?
Can you modify the Linux part, and if so does the proprietary software still run?
If those two criteria are satisfied I think you could probably successfully argue that they are cleanly separable components within a "mere aggregate". If not, they pretty clearly are bound together into a larger combined work.
> Can you delete the proprietary software, and if so does the Linux still run?
Generally, yes. Of course, some people have a custom init, and I don't think this really breaks things.
> Can you modify the Linux part, and if so does the proprietary software still run?
Yup, generally. Of course, the device itself may prohibit you from loading arbitrary software on it without rooting it or modifying the bootloader. You may not have a license to run the proprietary software with modified Linux, though.
You mention android smartphones above. The existence of LineageOS, etc, is evidence enough that you can do these things.
Generally, if you modify either the Linux part OR the proprietary part on a smartphone, the machine will fail to boot (i.e. the software will not run). This is a deliberate design goal, cryptographically enforced, and it is not implemented in physical hardware, but in the very software in question - the boot process includes some sort of "integrity check". This is the clearest possible statement of intent to integrate the two into a single combined work.
It boils down to the distinction between "derived work" and "mere aggregate", which is currently legally vague. This vagueness has allowed all sorts of shenanigans that violate the spirit of the GPL.
TiVo-ization is, releasing your code as FOSS, but enforcing in your hardware that you can only run vendor signed builds on the device, preventing users from running their own modifications to the software.
Most enterprise linux derivatives do not bundle proprietary linux modules with a modified linux kernel.
TiVo, like all such products, ran proprietary software "on top" of the Linux kernel (and "underneath", typically, in the form of a closed source bootloader). As far as I know, no company bothers to apply such DRM unless they do this. So this is kind of a distinction without a difference.
The user space interface is explicitly supported to run proprietary software. It's an operating system. The kernel's license taints things that are tightly coupled with it. Even most modules are not this tightly coupled and can deal with the exported symbols.
Similarly, the loader, BIOS, etc, are not encumbered by the kernel license.
We are specifically addressing what happens when you take a Linux kernel (or any other GPL code), modify it, and bundle it with proprietary software, in such a way that neither the free nor proprietary software function without the other. I am arguing that, regardless of the technical details, this constitutes a derived work (and not, as is commonly argued, an "aggregate").
The FSF gently disagrees with me. Tellingly, they won't commit to a clear distinction between "derived" and "mere aggregate", calling it a "legal question", but suggest that "a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)." I say this is a classic nerd mistake of reaching for technical solutions to social problems - the true criterion should be something more like "can the user run these components independently?".
It stems from a "nerdy" interpretation of "linking" that considers as relevant the fact that the monolithic proprietary blob (encrypted, protected, unmodifiable) has some sort of internal interface that mirrors the way a user might use a hypothetical free version of the product (running proprietary processes on a free kernel/userland). But it ignores the fact that the user cannot in practice disentangle the product in any way. It is the user experience that should legally be the deciding factor.
I realize this may be a controversial stance, but consider - what if I released a proprietary and closed source desktop application that bundled into its binary a copy of the Linux kernel? Are the specifics of how it interacts internally with this code really relevant? Is this really a different situation than code that runs bare metal?