Some binary blobs are just firmware, and so you just need to know how to load it into the radio - this is generally trivial to port to something else. However you still need to know how to access the blob and that is often restricted.
Even where it needs to run in the local OS, it is physically soldered onto a board - nobody is going to put it in a different phone so the CPU is already know. As such it isn't hard to write an emulator for the parts of the host OS it needs. *BSD can run linux apps as if on a native linux kernel (they are generally a few years behind the latest linux kernel but that is typically good enough), and Wine allows running windows apps: the same thing can apply to blobs that need to run in your OS. However you need to know how to access the functions in the blob which is often not known.
Of course it is possible for a blob read/write to random places in memory in a way that works only for a specific kernel. If a blob does this it is very difficult to port to anything else (you have to figure out where it might write and ensure you never use that memory). This is rare and evil enough that if a blob is caught doing this kernel developers will make changes such that the blob won't run (blobs that do this tend to have bugs such that the entire OS is unstable and users blame the OS not the blob)
Comments
Pass legislation that requires manufacturers of modem chipsets to open-source their firmware and driver blobs. That's the biggest obstacle.
We don't need open source blobs, we just need documentation on how to use them.
Open source blobs would be good for other reasons, but it isn't required to use them.
If all you have is a binary blob, doesn't that prevent you from ever recompiling it for use on a new OS or kernel?
That is normally irrelevant where it is true.
Some binary blobs are just firmware, and so you just need to know how to load it into the radio - this is generally trivial to port to something else. However you still need to know how to access the blob and that is often restricted.
Even where it needs to run in the local OS, it is physically soldered onto a board - nobody is going to put it in a different phone so the CPU is already know. As such it isn't hard to write an emulator for the parts of the host OS it needs. *BSD can run linux apps as if on a native linux kernel (they are generally a few years behind the latest linux kernel but that is typically good enough), and Wine allows running windows apps: the same thing can apply to blobs that need to run in your OS. However you need to know how to access the functions in the blob which is often not known.
Of course it is possible for a blob read/write to random places in memory in a way that works only for a specific kernel. If a blob does this it is very difficult to port to anything else (you have to figure out where it might write and ensure you never use that memory). This is rare and evil enough that if a blob is caught doing this kernel developers will make changes such that the blob won't run (blobs that do this tend to have bugs such that the entire OS is unstable and users blame the OS not the blob)
Doubt it. Frequency related laws mean it is unlikely any company would want to give the ability to modify anything that emit radio and microwaves.