child process VS child thread

Yesterday I received a mail from my brother telling me, that my explanation of a child process is wrong in some points. He claims that a child in general has more in common with a thread. Just read his explanations and tell me, what you think of it:

1. What about ressources? A child-process in this context uses a lot of
   the parents ressources and is therefore running in the same memoryspace
   as the parent does.
2. A child process is created by two parent processes. Normally. 
3. In the first few month the communication between parent and child
   is often disturbed by interferences, so only a heuristic-based
   communication can be established to process the childs I/O.
4. Most child processes develop a certain affinity for distance after a
   specific runtime and begin to become parents themselves caused
   by an own memoryspace.

So, the only suitable explanation can be as follows:

In reality it is not a child process, but a thread (see 1), which is created
because of inconsistence in the process communication between the parents
and starts to bed in a designated parent process (see 2). If a certain runtime
has passed, the thread becomes more and more resource-hungry so that
a separate process is started, which inherits all the properties of the former
thread. Due to the lack of documentation, the communication between the
three processes has to be defined at runtime, which normally lasts a few
month (see 3). If everything has developed as planed, the childs database
grew in a way, that the restrictive policy of the parents is no longer acceptable
(see 4).

Thanks to my brother Markus for bringing my attention to these issues.

I promise: The next time I'll do my homework before blogging