Re: Questions

[linas linas org (Linas Vepstas)]

Hi Bill,

Hey, good note, you're something like #1 on my 'rebuttal list',
and that's a compliment.

On Wed, Dec 05, 2001 at 02:51:51PM -0600, Bill Gribble was heard to remark:
> On Wed, 2001-12-05 at 14:09, Linas Vepstas wrote:
> > I asked these same questions of an intellectual property lawyer nearly
> > ten years ago. After some confusion, a fairly clear answer emerged:
> > the boundry lines lie along address spaces (virtual or not).  Since
> > processes are in different address spaces, there is no contamination.
> 
> I think you're mostly on the right track.  The FSF's GPL FAQ has a 
> pretty practical statement of rules of thumb for this in the "plug in"
> case, which I think is sort of the heart of the matter. 

I was trying to be 'more correct', since the gpl-faq alludes to 
unix concepts 'fork/exec'.  Not all OS's have this concept.  

The other problem with the GPL FAQ is that it alludes to 'different
processes', which is again a unix-ism, and gets murky if the 
code is called through an interrupt table or other trap/exception
mechanism.  Is an interrupt a 'different process', or a 'library 
call'?  You can make compelling arguments in either direction.  

This is OK for a FAQ, because the FAQ is supposed to be
'plain english'.

However, this becomes an interesting issue in things like embedded 
systems, and also in mainframes; or George's VMware example,
where things can get murky if you allow them to...

And, in the other direction: (this is a rhetorical question):
isn't an XML-RPC call a 'library call'?  There's no 'obvious'
fork/exec (its indirect at best), and there's not obviously a 
'separate process', since the PC in RPC is 'proceedure call'.
Yet, its "obvious" (I hope) that a GPL'ed XML-RPC server
can eb called by a proprietrary XML-RPC client.

In order to avoid the murkiness about what is or is not a process, 
and what does or does not consitute a true fork/exec, the better
rule of thumb is the address space.  Address spaces have a grounding 
in hardware that processes do not.  The trend in CPU design is
to eliminate per-process context, because that way you can have 
low-cost/no-cost context switches.   Think 'lisp machine', 
is 'eval' a process? or a call?   Or the dataflow architectures, 
where you try to schedule every instruction as if it were a process, 
and so you wouldn't have something like the linux scheduler to 
context switch or mediate time slices.  This isn't enirely 
academic: modern out-of-order execution & register-coloring 
design borrows more or less directly from the earlier dataflow 
archs. 


--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas linas org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933