I am not so sure about that. I think I remember from a very very old memory that, actually, this specific case has been encountered or discussed and that the answer is no, you aren't allowed to do that.
Basically, if you create your own custom protocol etc. You are just reinventing an inefficient wheel, but it's still a wheel. It's still linking.
The whole process could even be automated otherwise, nullifying the gpl effectively.
I am NOT a lawyer. And maybe it depends on the country (it seems USA has a very "what-the-law-say-exactly" while France (and maybe Europe) tend to look at the "spirit" of the law.
"Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe 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).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
I am not sure I understand what you say (despite having read your message several times), but pointers don't have all the same size. Not always, at least.
(void* is supposedly big enough to contain any type of pointer, even if I think I remember I read that it's not necessarily true for function pointers).
And if the size of "void" and "char" aren't the same you cannot push two void* on the stack and pop two char*.
But, like I said: maybe I didn't understood what you said.
Some thoughts.
1/ I think that it's not always possible to modify the domain. For example, I could have a function that takes a name of a file as parameter and returns a CanBeWritten object. Now, I could have a function that open a file in write mode and take an object of this type as parameter.
The issue is that between the moment I acquire this object and the moment I use it, the file could, you in fact, become non-writeable.
(There was a post on hn about this idea of using the type system like this https://news.ycombinator.com/item?id=35053118 ).
I think you focus a lot on software issues and neglect the hardware ones. But it's a choice.
Still my thoughts (but at this point you already understood that it was going to be like that the entire post): I think that when a fault is detected (when it becomes a failure if I follow your definitions), an attempt to fix the problem and return to a normal state can actually fail - by incorrectly fixing the issue. Like: you have three times the same integer (redundancy) and one of them have a bit flipped.
You decide that the one different from the two other is the incorrect one.
You detected a problem, you tried to fix it. But it could be the case that two bitflips occured at the same position.
There is no definitive solution to that, but documenting all the detected problems AND the fixes applied to them would help.
And for the error messages ... Well, my position is that most of the time they are useless for the end user. They can be useful for the developer. For the end user, the best error message (if such a message is required) is something unique enough to be copy-pasteable on Google to find a solution that the user will not understand but will be able to apply.
I used to consider (when I started computer science) that an algorithm is like going from point A to point B on a city map. There is essentially one "good" path and a huge quantity of "wrong" paths were you can get lost. And by trying to find your way, you can make the situation even worse.
The whole process could even be automated otherwise, nullifying the gpl effectively.
I am NOT a lawyer. And maybe it depends on the country (it seems USA has a very "what-the-law-say-exactly" while France (and maybe Europe) tend to look at the "spirit" of the law.
EDIT more about this question here ? https://news.ycombinator.com/item?id=15105920
EDIT 2:
(Rpc are listed)
https://www.gnu.org/licenses/gpl-faq.en.html
"Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe 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).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."