Re: Questions

[linas linas org (Linas Vepstas)]

On Wed, Dec 05, 2001 at 04:53:17AM -0800, George was heard to remark:
> On Wed, Dec 05, 2001 at 12:01:06PM +0000, Alan Cox wrote:
> > > A "derivative work" is a work based upon one or more preexisting works,
> >                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > So, which of these covers merely ulizing another program?
> > 
> > Duh

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.
Since libraries usually are not, there isn't.

'different adress space' is usually "obvious" when its a different 
CPU, connected by ethernet.  When the different CPU is connected by
some other means then its tricker. Lets be ccomplete: 
connected by bus, e.g. by a memory bus (SMP on same CEC, 'central
electronics complex' aka motherboard, or two CPU's on same chip),
i/o bus (another CPU on an adapter card) or shared-mem ethernet 
device (yes, there are weird cards that make it look like you
have 'shared memory' with a remote cpu -- i.e. make it SMP-like
with a cpu that's a kilometer away).  In these cases, the criterion
is:

-- different virtual address space, as administered by an OS kernel
   without hardware support,
-- different virtual address space, as administered by hardware,
   e.g. TLB's (translation look-aside buffers), page tables, and 
   other hardware mechanisms that create explicit, impregnable 
   boundries.

-- (Note that IBM mainframes have a special hardware that allows 
   different libraries to live in different address spaces.  With
   complete address space security.  If intel/sparc/mips/powerpc
   had this ability, then we *could* have implemented the x-server
   entirely as a library, since there would have been no way for
   an x client to trash the guts of the x server.  Under unix
   and NT, the reasons that 'servers' are processes instead of 
   libraries is because there is no address space protection
   between across unix library calls.  In unix, if you want
   protection against corruption/malicious code/hackers, you 
   have to use different processes to get different address spaces.
   More on this subtle but important point below.)


> Well, it depends on your definition of 'based upon'.  

The normal definition is 'incorporates source code derived from'

> For example a
> proprietary xterm replacement might still run bash as a shell.  Does this
> constitute infringment?  

No, as long as the xterm didn't use source code from bash.
since bash runs in a different address space than xterm, its not
contaminated.

> Or if a proprietary software does:
> 
> system ("cp foo bar");
> 
> And it is run on a system where cp is a GPLed utility?

Same answer as above. system() is a kernel call.  The kernel is
considered to be in its own address space (since the kernel runs in 
supervisor state, you can try to argue this, but again, the common
legal perception is that the kernel is distinct.) so the kernel can 
be GPL'ed without contamination the proprietary program.  And cp is
certainly in a differnt addres space.

> However I'm not claiming knowledge of the Copyright Law.  (Mostly because I'm
> not able to fake it enough).  Also really I don't care what proprietary
> software must or must not do.  However it does pose a question for non-GPL
> compatible free software.

I am not a lawyer.  I don't know how much of this 'address space' stuff
is codified in court rulings, although I was lead to beleive a lot of it 
was settled in the 1960's/70's, with IBM as a party ...

Similar lines of argument can be used when talking about auto-generated
code (compiled, vs. interpreted, m4 macro'ed, config filed, e.g. what
glade does with the dynamic libglade xml files).

> Can such a software use an out-of-process GPL component?  

Yes. The boundry is not the process boundry, but the address space
boundary.  Process boundaries are murky, because one process can
cause another process to do something it otherwise wouldn't have done.
That is, any IPC, whether shmem, semaphore, pipes, tcpip, or even the
'system()' 'execve()' syscalls, etc. tends to 'feel like' a library 
call because the cause-effect relationship is the same as a library 
call.  That is why you asked te questions about system ("cp src dest"); 
because this "feels like" a library call, and thus it "feels like" 
a violation of the GPL when cp is GPL'ed.

The cause-n-effect model is totally contaminating: your prorpietary 
web browser can make a library-like cause-n-effect action on my 
GPL'ed webserver.


> If the component is
> not 'required', that is the user does some action to activate it.  Isn't this
> sort of like running it in a shell or something.  (Thus I could run a GPL
> program from a non-GPL compatible shell).  

Answered above.

> Also, does the law know the
> difference between in-process and out-of-process.  To me it doesn't seem like
> such a fundemental difference.  

It isn't, and that's the point.

> Imagine that you would write an emulator for
> linux x86 ELF binaries.  Then if you load the binary into the emulator you're
> running it in-process.  The binary itself doesn't know.  So can you run GPLed
> code in a non-GPL compatible emulator?  

yes.  The emulator provides an address space to the emulated binary.
The emulated binary cannot 'break out' of that address space to 
corrupt the emulator, or corrupt the address spaces of other emulated
binaries that might also be running.  (bugs don't count).

Note that e.g. the transmeta chips are 'emulators' in a sense, and
they're proprietary.  Transmeta chips aren't the first semi-hardware
emulators ever built.  Rather totally weirdly, a lot of the mainframe
'hardware', what looks-n-feels like hardware to the programmer, is 
in fact a giant and complex emulator under the covers.  They don't
advertise this.

> So wouldn't running Linux under
> VMware be license infringement?  

No.

> I'm rambling, it's 4am.  

Let me ramble.  There's an interesting case of GPL vs. LGPL when
the the hardware supports distinct different address spaces for
libraries.  If the library is GPL'ed, but lives in its own address
space, then I beleive that it would not 'infect' the calling program.

If you stand on your head, the linux kernel is kind-of like this.
When you make a system call (e.g. 'write()' ) into the linux kernel, 
its not just an ordinary subroutine call into an ordinary library.  
There is some special funny assembler linkage code that causes
an address space switch to occur.  Once you are in the kernel,
you are still in the same 'process' (the linux current process 
pointer has not changed. The FPU context hasn't been changed,
other CPU context, such as misc masks and bits haven't changed.  
The stack pointer is still using the same process stack. So
you really are in the 'same process' in a certain definite sense.)  
So unix system calls are a kind of 'library call' that changes 
the address space, but not the process.  

The Linux kernel is GPL'ed, but I can run proprietary software on 
it.  How can this be, when a linux system call is essentially a 
library call?  Answer: its because the address space changed in
the call linkage, when the 'svc' instruction caused a very special
trap to occur.


--linas

p.s. IANAL. And since lawyers like to argue, presumably they have 
ways of twisting the above out of shape.


-- 
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